Desaster Recovery und Replikation

Wie funktioniert Replikation?

Auch die beste Hardware der Welt kann ausfallen. Die Zeiten, in denen Datenbestände auf Magnetbänder gesichert wurden, und im Falle eines Systemabsturzes wieder daraus rekonstriuert werden konnten, sind vorbei. Noch vor wenigen Jahren waren systembedingte Ausfallzeiten von 2 oder 3 Tagen normal, Datenverluste seit der letzten Sicherung waren einkalkuliert und wirkten sich oft nicht so dramatisch aus als heute, wo viele Unternehmen ihre gesamten Produktions-, Kunden- oder Buchhaltungsdaten elektronisch verwalten oder miteinander vernetzen. Damit werden die Verfügbarkeit der Systeme und die Minimierung von Ausfallzeiten zu Erfolgsfaktoren. Einen kompletten Datenverlust würden nur wenige Firmen überleben und selbst die Kosten für Systemausfälle von einigen Stunden ziehen mitunter Kosten in astronomischer Höhe nach sich. Um sich einen Eindruck zu verschaffen, können Sie sich auf der Seite http://www.maxdata.de/downtime-calculator/default.asp die Kosten eines Systemausfalls berechnen lassen.

Die alte Methode eines lokalen Backups reicht offensichtlich nicht mehr aus. Redundante und kontinuierliche Speicherung aller wichtigen Daten an verschiedenen Orten ist nicht nur 'nice to have', sondern zu einer wirtschaftlichen Notwendigkeit geworden. Die kontinuierliche Duplizierung der Daten von einem primären Server (Master) auf einen oder mehrere entfernte sekundäre Server (Slaves) wird Replikation genannt. Disaster Recovery ist nicht die einzige Motivation für Replikation: mit diesen Techniken können auch andere Ziele verfolgt werden, beispielsweise eine Lastverteilung auf mehrere Server. Für Datenbanken kann ein Pool von Datenbankverbindungen eingerichtet werden, so dass Transaktionen auf verschiedene Server verteilt werden können. Selbstverständlich müssen diese Server dann regelmäßig miteinander synchronisiert werden. Ein Vertreter dieser Technologie für PostgreSQL ist pgpool.

Abhängig von den Zielen und Erfordernissen können unterschiedliche Techniken zur Replikation eingesetzt werden. Für kritische Anwendungen muss es nach einem Systemabsturz möglich sein, in kürzester Zeit wieder auf vollständige und konsistente Daten zuzugreifen. Andere Anwendungen wiederum verkraften einen minimalen Datenverlust oder können sich längere Ausfallzeiten erlauben. Dementsprechend gibt es zwei grundlegende Techniken zur Replikation: synchrone und asynchrone Replikation.

Bei einer synchronen Replikation einer Datenbank werden alle Änderungen der primären Datenbank ohne Verzögerung auf die sekundären Datenbanken geschrieben, so dass dort immer identische Kopien der originalen Datenbank vorliegen. Alle beteiligten Server verständigen sich über erfolgreiche Schreibtransaktionen, bevor ein erneuter Schreibzugriff auf der primären Datenbank zugelasen wird. Das Konzept dahinter ist ein sogenannter 2-Phasen-Commit. Eine Transaktion wird abgeschlossen, wenn alle verbundenen Server die Transaktion akzeptieren. Genauso muss eine misslungene Transaktion eines einzigen Servers in allen anderen Servern zurückgerollt werden. Das Ergebnis ist eine sofortige Synchronisation der Daten, bei der keine committeten Transaktionen verlorengehen können. Allerdings geht diese Sicherheit zu Lasten der Performance, da die primäre Datenbank auf die Bestätigungen aller entfernten, sekundären Datenbanken warten muss, bevor sie die Transaktion abschliessen und neue Transaktionen ausführen kann. Damit ist die Leistungsfähigkeit des Systems sowohl proportional zur Anzahl der sekundären Datenbanken als auch zur Geschwindigkeit der Datenübertragung, und damit teuer, wenn man Übertragungswege mit hoher Bandbreite einsetzt. Synchrone Replikation für PostgreSQL bieten die Programme pgpool oder PGCluster.

Bei der asynchronen Replikation sind Schreibvorgänge auf der primären Datenbank und den Kopien entkoppelt. Die Aktualisierung der Kopien erfolgt zeitverzögert, mit dem Risiko, dass die Versionen nicht unbedingt synchronisiert sind. Möglicherweise wurden auf dem Master Transaktionen committet, die zum Zeitpunkt eines Absturzes noch nicht auf den Slaves nachgetragen sind. Diese Trsansaktionen gehen im schlimmsten Fall verloren.

Asynchrone Replikation bedingt keine Wartezeiten für Schreibvorgänge auf der Master-DB, da keine Bestätigungen von den Slaves abgewartet werden müssen. Änderungen der primären Datenbank werden gespeichert und später in die Kopien geschrieben. Diese Speicherung kann in Log-Dateien erfolgen, die über das Netzwerk transferiert und aus denen die Kopien aktualisiert werden. Mit dieser Technologie arbeitet Mammoth für PostgreSQL.

Andere Implementierungen, speichern die Schreiboperationen des Masters in Warteschlangen, aus denen die Updates an die Slaves ausgeliefert werden oder sie legen spezielle Tabellen an, in denen alle Änderungen der primären Datenbank von Triggern gespeichert werden. In periodischen Zeitintervallen werden alle diese Änderungen in Schreibzyklen auf die sekundären Datenbanken repliziert. Wichtig bei allen diesen Verfahren ist, dass sie die zeitliche Reihenfolge der Änderungen gewährleisten, weil sonst die Integrität der Slaves nicht gewährleistet werden kann.

Eine vollkommen andere Art der Replikation besteht darin, von Zeit zu Zeit komplette Snapshots der primären Datenbank an die Slaves zu übermitteln. Damit sind die Slaves in einem konsistenten Zustand und das Problem der zeitlichen Abfolge von Transaktionen besteht nicht. Bei sehr grossen Datenbanken führt dies zu sehr langen Schreibzyklen und eine Auswahl der zu replizierenden Tabellen ist so nicht möglich.

Wegen der Entkoppelung von Schreibzugriffen auf Master und Slaves können Ausfälle von sekundären Servern oder Verbindungen toleriert werden. In diesem Fall müssen die Transaktionen in einem dauerhaften Speicher protokolliert werden, bis der Slave wieder betriebsbereit ist.

Asynchrone Replikationsverfahren arbeiten entweder im Read-Only- oder Update-Anywhere-Modus. Im Read-Only-Modus werden alle Änderungen vom Master zum Slave repliziert, aber nicht umgekehrt. Im Update-Anywhere-Modus kann in allen Datenbanken gelesen und geschrieben werden und Änderungen können in beide Richtungen repliziert werden.

Datenreplikation reduziert die Möglichkeiten eines Datenverlustes erheblich und beschleunigt gleichzeitig die Wiederherstellung der Produktionsdaten. Im Ernstfall können Anwendungen in kurzer Zeit auf einen sekundären Server umgeleitet werden, und dort ohne, oder mit nur geringem Datenverlust weiterarbeiten.