Ausfallsicher: Zwei Datenbanken parallel ?

[Kalle_B]

Hallöle,

mein Auftraggeber erwartet von mir einen Vorschlag, wie eine Datenbank im Internet "ausfallsicher" gemacht werden kann.

Meine Idee ist, PHP- Software und MySQL-Datenbank bei zwei getrennten Providern zu installieren. Im Ernstfall könnte man per Mausklick umschalten.

Hat jemand Erfahrung mit der Parallelführung von Daten?

Zuerst müsste ich die vorhandene Datenbank kopieren (Nebeneffekt: Datensicherung, evtl. sogar zusätzlich auf einen lokalen Server), also Tabellenstruktur und Daten von der bereits vorhandenen Datenbank übernehmen. Daten sind mir klar, aber mit welchem Kommando verrät eine Tabelle ihre Struktur (okay, habe noch nicht recherchiert).

Und dann müsste ich bei jedem Programmlauf BEIDE Datenbanken aufmachen, um jedes INSERT, DELETE und UPDATE (was vergessen?) zweimal abzusetzen.

Ist die Idee realistisch?

Lieben Gruß aus Birkenau, Kalle

[Erwin]

Hi,

Hat jemand Erfahrung mit der Parallelführung von Daten?

Schau mal nach Replikation.

... aber mit welchem Kommando verrät eine Tabelle ihre Struktur

MySQL: mysqldump -d <datenbank> <tabelle>

Ist die Idee realistisch?

eher nein!

• Erwin -

[Fischi]

Hi,

mein Auftraggeber erwartet von mir einen Vorschlag, wie eine Datenbank im Internet "ausfallsicher" gemacht werden kann.

Meine Idee ist, PHP- Software und MySQL-Datenbank bei zwei getrennten Providern zu installieren. Im Ernstfall könnte man per Mausklick umschalten.

Hat jemand Erfahrung mit der Parallelführung von Daten?

ja. Prüfe zuerst, ob Dein RDBMS (MySQL) Replikationen unterstützt. Falls ja, dann müsstest Du nur die Replikation einstellen und hättest programmseitig (bspw. PHP und so) nichts mit der redundanten Datenhaltung am Hut.

Und dann müsste ich bei jedem Programmlauf BEIDE Datenbanken aufmachen, um jedes INSERT, DELETE und UPDATE (was vergessen?) zweimal abzusetzen.

Das wäre "Plan B", korrekter und pflegeleichter und einfacher wäre die o.g. Lösung. Eventuell kommst Du auch mit einem anderen RDBMS, M§SQLServer ist nicht schlecht für Deine Anforderungslage.

Alternativ könntest Du das Problem auch rein hardwareseitig bearbeiten, also mit RAIDs kommen und einem Zweitrechner. Geigt dann der Erstrechner oder eine Platte auf dem Erstrechner ab, dann lässt Du den Zweitrechner online gehen. Hier lässt sich Redundanz einfach einkaufen und möglicherweise ist eine reine Hardwerelösung auch Richtung Abnehmer gut vermittelbar?!

Fischi

[Frank (no reg)]

Hi,

frag deinen Auftraggeber doch mal, gegen welche Ausfallrisiken er die
Datenbank absichern will? Und geht es wirklich nur um die Datenbank?

Die "geeigneteste" Methode hängt von genauerer Anforderungsformulierung
ab.

Ciao, Frank

[Kalle_B]

Hi,

frag deinen Auftraggeber doch mal, gegen welche Ausfallrisiken er die Datenbank absichern will? Und geht es wirklich nur um die Datenbank?

Es geht um einen Messebetrieb. Letztes Jahr war in der heissen Phase der Server einige Stunden nicht erreichbar. Fünf Leute saßen rum, drehten Däumchen und die Zeit lief ... Das hat einen Schock hinterlassen. Ist sowas wie Bandstillstand bei VW.

Es geht nicht nur um die Datenbank, auch um den Provider und die Internet- Verbindung überhaupt.

Falls das Internet ausfällt, werden wir dieses Jahr einen lokalen Server mitnehmen zur Messe, der kurz vor Anreise noch den aktuellen Datenstand bekommt. Aber der ALLEIN reicht nicht, er könnte ja selbst ausfallen.

Habe schon erste Tests gemacht mit Parallelbetrieb, zumindest zwei Datenbanken bei zwei Providern mit einem Programm geöffnet. Okay, ist kein besonderer Zauber, aber ich wusste nicht, ob PHP "fremdgehen" (auf andere Server zugreifen) kann.

Der nächste Schritt ist, Tabellen von A nach B zu kopieren.

Kalle

[Frank (no reg)]

Hallo,

du hast also grundsätzlich folgende Risiken:

• Softwarefehler
    - die Datenbanksoftware will nicht mehr
    - die PHP Software will nicht mehr
• Hardwareausfall
    - der DB Server fällt aus
      - I/O Ausfall (defektes I/O Subsystem)
      - Gesamtausfall (PSU, CPU, Ram ...)
    - der Applikationsserver fällt aus
      - ... selbe mögliche Gründe
• Verbindungsausfall
    - die Verbindung zur PHP Applikation ist weg (Providerausfall)
    - die Verbindung zwischen PHP und DB ist weg (internes Provider-Netzwerk-Problem)

Gegen SW Fehler schützt man sich (u.a.) durch

• robuste Programmierung (gute Fehlerbehandlung)
• einfache Wartbarkeit (Dienste sind einfach, schnell und manuell neu-startbar) für den Fehlerfall

Gegen HW Fehler schützt man sich (u.a.) durch

• RAID-basierte IO-Subsysteme
• Redundante Stromversorgung (USVs etc)
• Virtualization (z.b. redundante Blade-Server mit gemeinsamen SAN) oder auch Clustering
• Cold / Hotstandby Komplettsysteme (also Hardware- und Installations-gleiche Systeme, so dass fehlerhafte Komponenten ausgetauscht oder reine Daten einfach überspielt werden können)

Gegen Konnektivitätsfehler schützt man sich (u.a.)

• in deinem Fall wohl am besten durch einen lokalen Server direkt auf dem Messestand
• durch die Auswahl eines zuverlässigen Providers der ein SLA (Service Level Agreement) bietet, was deine Risiken zur Konnektivität abdeckt:
    - redundante Backbone Anbindung
    - redundantes internes Netzwerk
    - genügend Ersatzmaterial ;)
    - eventuell auch Clustering

Ist sowas wie Bandstillstand bei VW.

So was gibt es, aber dann sicher nur in deutschen Werken ? ;)

Aber der ALLEIN reicht nicht, er könnte ja selbst ausfallen.

Meine o.g. Stichworte sollten dir helfen, ein geeignetes Szenario für die Vermeidung deiner Risiken zu erarbeiten.

Der nächste Schritt ist, Tabellen von A nach B zu kopieren.

MySQL kennt doch dump befehle, mit denen du die ganze DB übertragen kannst. Wenn du an einer Internetlösung festhalten willst, dann
solltest du vllt. mit dem Provider vereinbaren, dass regelmäßig solche Dumps oder reguläre Backups gemacht werden und redundant zur Verfügung (für Download ... usw) gestellt werden.

Verfügbarkeit und Sicherheit hat ihren Preis, nur noch am Rande erwähnt.

Ciao, Frank