Replication: Daten auf mehrere Knoten kopieren

Datenarchitektur

Replication

Daten auf mehrere Knoten kopieren

Die Idee und ihr Nutzen

Eine Versicherung speichert den Status ihrer Schadenfälle in einer Datenbank. Die Sachbearbeitung soll Fall 4711 auch dann öffnen können, wenn der Rechner dieser Datenbank ausfällt. Deshalb liegen Kopien derselben Daten auf weiteren Rechnern. Der Rechner, der alle Änderungen annimmt, heißt Primärknoten; Knoten ist das übliche Wort für einen Rechner in einem solchen Verbund. Jede Änderung, die der Primärknoten speichert, überträgt er an diese Kopien. Ändert die Sachbearbeitung den Status von Fall 4711 auf „freigegeben“, steht dieser neue Status kurz darauf auch in jeder Kopie. Fällt der Primärknoten aus, kann eine Kopie seine Aufgabe übernehmen. Das fortlaufende Übertragen der Änderungen auf Kopien heißt Replication, auf Deutsch Replikation.

Bausteine: Schadendienst: ändert den Status von Fall 4711; Primärknoten: nimmt jede Änderung an; Kopie 1: bestätigt jede Änderung; Kopie 2: hat kurz noch den alten Stand. Verbindungen: Schadendienst — Primärknoten; Primärknoten → Kopie 1; Primärknoten → Kopie 2. Der Primärknoten überträgt jede Änderung an beide Kopien, wartet aber nur auf die Bestätigung von Kopie 1.

Wie funktioniert es?

Der Schadendienst, das Programm für die Bearbeitung von Schäden, ändert den Status von Fall 4711 von „in Prüfung“ auf „freigegeben“. Der Primärknoten nimmt die Änderung an und speichert den neuen Status. An Kopie 1 überträgt der Primärknoten die Änderung synchron: Der Primärknoten wartet, bis Kopie 1 „gespeichert“ zurückmeldet, und erst danach erhält der Schadendienst die Erfolgsmeldung. An Kopie 2 überträgt der Primärknoten die Änderung asynchron, also ohne auf Kopie 2 zu warten. Kopie 2 holt den Stand etwas später nach. Das Kundenportal, über das Kunden den Stand ihrer Schäden abrufen, liest unmittelbar nach der Erfolgsmeldung von Kopie 2. Kopie 2 hat die Änderung noch nicht und meldet „in Prüfung“. Auch bei Kopie 1 hängt es von der Einstellung der Datenbank ab, ob eine Leseanfrage den neuen Status schon sieht. Manche Datenbanken bestätigen eine Änderung schon, wenn die Kopie sie dauerhaft gespeichert hat. Für Leseanfragen sichtbar macht die Kopie die Änderung erst danach. Kopie 1 kann dann schon „gespeichert“ gemeldet haben und auf eine Leseanfrage trotzdem noch „in Prüfung“ liefern. Eine Auszahlung soll auf dem neuen Status beruhen. Deshalb liest der Zahlungsablauf, das Programm für Auszahlungen, vom Primärknoten und erhält „freigegeben“, also den bestätigten Stand.

Bei der Replikation werden drei Dinge leicht verwechselt: wann der Primärknoten dem schreibenden Programm eine Änderung bestätigt, wie aktuell eine Kopie beim Lesen ist und welche Kopie mit welchem Stand bei einem Ausfall des Primärknotens übernimmt. Das Entwicklungsteam legt deshalb alle drei ausdrücklich fest. Für jede Kopie bestimmt es, ob die Kopie synchron oder asynchron angebunden ist. Eine Regel für das Lesen bestimmt, welche Leseanfragen von einer möglicherweise älteren Kopie lesen dürfen und welche vom Primärknoten oder von einer nachweislich aktuellen Kopie lesen müssen. Diese Regel lässt sich nicht der Datenbank allein überlassen, weil die richtige Wahl davon abhängt, wofür der gelesene Wert verwendet wird. Für die Anzeige im Kundenportal genügt Kopie 2, für eine Auszahlung braucht der Zahlungsablauf den Stand des Primärknotens. Eine Regel für den Ausfall bestimmt, welche Kopie übernimmt, wenn der Primärknoten ausfällt, und wie festgestellt wird, welche Änderungen dieser Kopie fehlen.

Fällt der Primärknoten aus, übernimmt nach der Regel für den Ausfall eine Kopie die Aufgabe des Primärknotens und nimmt ab dann die Änderungen an. Hat die übernehmende Kopie jede bestätigte Änderung synchron erhalten wie Kopie 1, fehlt ihr keine davon. Bei einer asynchron angebundenen Kopie wie Kopie 2 können die letzten bestätigten Änderungen fehlen.

Beteiligte: Schadendienst: ändert den Status von 4711; Primärknoten: nimmt Änderungen an; Kopie 1: synchron angebunden; Kopie 2: asynchron angebunden; Kundenportal: liest von Kopie 2; Zahlungsablauf: braucht den bestätigten Stand. Ablauf: 1. Der Primärknoten nimmt den neuen Status „freigegeben“ für Fall 4711 vom Schadendienst an und speichert ihn. 2. Der Primärknoten überträgt die Änderung synchron an Kopie 1 und wartet auf die Bestätigung. 3. Kopie 1 meldet „gespeichert“. Erst danach meldet der Primärknoten dem Schadendienst den Erfolg. 4. Der Schadendienst erhält vom Primärknoten die Erfolgsmeldung. 5. Der Primärknoten überträgt die Änderung an Kopie 2, ohne zu warten. Kopie 2 holt den Stand etwas später nach. 6. Das Kundenportal liest unmittelbar nach der Erfolgsmeldung von Kopie 2. 7. Kopie 2 hat die Änderung noch nicht und meldet „in Prüfung“. Auch bei Kopie 1 hängt es von der Einstellung der Datenbank ab, ob eine Leseanfrage den neuen Status schon sieht. 8. Weil die Auszahlung auf dem neuen Status beruhen soll, liest der Zahlungsablauf vom Primärknoten. 9. Der Zahlungsablauf erhält „freigegeben“, also den bestätigten Stand.

Wann ist es sinnvoll und wann nicht?

Replikation lohnt sich

Daten sollen auch beim Ausfall eines Rechners verfügbar bleiben. Ohne Replikation liegt der Status von Fall 4711 auf einem einzigen Datenbankrechner. Fällt dieser Rechner wegen eines defekten Netzteils aus, kann niemand den Fall öffnen, bis der Rechner repariert ist.
Daten dürfen bei einem Defekt nicht verloren gehen. Hat der einzige Datenbankrechner eine defekte Festplatte, sind die Daten seit der letzten Sicherung verloren. Mit Replikation enthalten die Kopien diese Daten bereits.
Viele Leseanfragen sollen auf mehrere Rechner verteilt werden. Ein Beispiel sind die Anfragen des Kundenportals. Ohne Replikation beantwortet der Primärknoten auch alle Anfragen des Kundenportals. Liest das Kundenportal von Kopie 2, hat der Primärknoten mehr Rechenleistung für Änderungen frei.
Die Daten sollen zusätzlich in einem zweiten Rechenzentrum bereitliegen. Ohne eine Kopie im zweiten Rechenzentrum fallen bei einem Stromausfall am ersten Standort der Primärknoten und alle Kopien zugleich aus. Mit Replikation in das zweite Rechenzentrum trifft eine Störung an einem Standort nicht alle Kopien zugleich.

Replikation ist nicht das Richtige

Replikation soll eine Datensicherung ersetzen. Eine versehentliche Löschung überträgt der Primärknoten an alle Kopien. Dann sichert das Betriebsteam die Datenbank zusätzlich regelmäßig, etwa jede Nacht. Aus einer solchen Sicherung mit einem früheren Stand stellt das Betriebsteam einen versehentlich gelöschten Fall wieder her.
Eine Ausfallzeit von einigen Stunden ist hinnehmbar, und ebenso der Verlust der Änderungen seit der letzten Sicherung. Kopien würden dann nur eine Ausfallzeit und einen Datenverlust verhindern, die beide hinnehmbar sind. Stattdessen sichert das Betriebsteam die Datenbank regelmäßig und übt die Wiederherstellung. Die Versicherung spart so die weiteren Datenbankrechner, die für die Kopien ständig laufen. Wie man festlegt, welche Ausfallzeit und welcher Datenverlust hinnehmbar sind, beschreibt Disaster Recovery (RPO und RTO).
Kopien sollen nur Leseanfragen abnehmen, aber jede Leseanfrage braucht den neuesten Stand. Asynchrone Kopien wie Kopie 2 würden womöglich alte Stände liefern, und auch eine synchrone Kopie wie Kopie 1 zeigt eine bestätigte Änderung je nach Einstellung der Datenbank erst etwas später. Dann lesen alle Programme vom Primärknoten, und das Betriebsteam setzt den Primärknoten bei Bedarf auf einen Rechner mit mehr Rechenleistung.
Die Datenbank soll beim Ausfall eines Rechners ohne Umschalten weiter Änderungen annehmen. Bei Replikation nimmt nur der Primärknoten Änderungen an, und fällt der Primärknoten aus, muss erst eine Kopie seine Aufgabe übernehmen. Dann richtet das Entwicklungsteam eine Datenbank mit gleichberechtigten Kopien ein, die nach dem Quorum arbeitet: Jede Änderung geht an alle Kopien und gilt als gespeichert, sobald eine festgelegte Mindestzahl von Kopien sie bestätigt hat, etwa zwei von drei. Fällt ein Rechner aus, bestätigen die zwei übrigen Kopien die Änderungen weiter.

Nachteile und typische Fehler

Jede Kopie braucht einen eigenen Rechner mit eigenem Speicher, und die Übertragung belastet das Netz. Bei synchroner Übertragung dauert jeder Schreibvorgang länger, weil der Primärknoten auf die Bestätigung wartet, besonders wenn die Kopie in einem entfernten Rechenzentrum steht. Bei asynchroner Übertragung entfällt diese Wartezeit, dafür kann eine Kopie für kurze Zeit den alten Stand liefern. Das Betriebsteam muss überwachen, wie weit jede Kopie hinter dem Primärknoten zurückliegt, und das Umschalten auf eine Kopie bei einem Ausfall regelmäßig üben.

Typische Fehler und woran man sie erkennt:

Verlorene bestätigte Änderung: Der Primärknoten bestätigt dem Schadendienst eine Änderung. Danach fällt der Primärknoten aus, bevor er die Änderung an die asynchron angebundene Kopie 2 übertragen hat. Nach der Regel für den Ausfall übernimmt Kopie 2 statt Kopie 1 die Aufgabe des Primärknotens, und Kopie 2 kennt diese Änderung nicht. Erkennbar ist das daran, dass der Schadendienst nach dem Umschalten einen Status vermisst, für den er eine Erfolgsmeldung erhalten hatte.
Blockierter Primärknoten: Die synchrone Kopie ist wegen einer Netzstörung nicht erreichbar, und der Primärknoten ist so eingestellt, dass er ohne die Bestätigung dieser Kopie keine Änderung bestätigt. Erkennbar ist das an Schreibvorgängen, die hängen bleiben, obwohl der Primärknoten selbst läuft.
Entscheidung auf altem Stand: Der Zahlungsablauf liest den Status von Kopie 2 statt vom Primärknoten und sieht noch „in Prüfung“. Die Auszahlung für den bereits freigegebenen Fall unterbleibt oder verzögert sich. Erkennbar ist das an Zahlungsentscheidungen, die nicht zum Status im Primärknoten passen.
Übertragene Löschung: Jemand löscht Fall 4711 versehentlich, und die Löschung erreicht alle Kopien. Erkennbar ist das daran, dass der Fall auf keinem Rechner mehr zu finden ist.
Zwei Primärknoten: Nach einer kurzen Netzstörung übernimmt Kopie 1 die Aufgabe des Primärknotens. Danach ist der alte Primärknoten wieder erreichbar und erfährt nichts vom Umschalten. Programme, die das Umschalten nicht mitbekommen haben, schicken ihre Änderungen weiter an den alten Primärknoten, die übrigen Programme schicken sie an Kopie 1. Beide Rechner haben danach verschiedene Stände. Erkennbar ist das an Schadenfällen, die je nach Rechner einen anderen Status zeigen.

Weiterführend

Quellen

Martin Kleppmann: Designing Data-Intensive Applications: Buch von 2017, dessen Kapitel zur Replikation Primärknoten und Kopien, synchrone und asynchrone Übertragung sowie Probleme durch zurückliegende Kopien erklärt.
PostgreSQL: Log-Shipping Standby Servers: Projektdokumentation, die beschreibt, dass bei asynchroner Übertragung bestätigte Änderungen bei einer Umschaltung verloren gehen können, und die unterscheidet, ob eine synchrone Kopie die Änderung nur dauerhaft gespeichert oder schon für Leseanfragen sichtbar gemacht hat.