Evakuierungsprozesse

Wenn dies bei einer MRSC-Tabelle passiert, müssen Sie nichts Besonderes tun. Globale MRSC-Tabellen unterstützen einen Recovery Point Objective (RPO) von Null. Alle erfolgreichen Schreibvorgänge in die MRSC-Tabelle in der Offline-Region sind auch in allen anderen Regionstabellen verfügbar, sodass keine potenzielle Datenlücke besteht, selbst wenn die Region ohne vorherige Ankündigung vollständig offline geht. Unternehmen können weiterhin Replikate verwenden, die sich in den anderen Regionen befinden.

Wenn dies bei einer MREC-Tabelle passiert, werden alle Schreibvorgänge in Region A, die noch nicht weitergegeben wurden, gespeichert und weitergegeben, nachdem Region A wieder online ist. Die Schreibvorgänge gehen nicht verloren, doch ihre Weitergabe verzögert sich um unbestimmte Zeit.

Wie in diesem Fall vorzugehen ist, entscheidet die Anwendung. Um die Geschäftskontinuität zu wahren, müssen Schreibvorgänge möglicherweise in die neue Primärregion B übertragen werden. Wenn jedoch ein Element in Region B eine Aktualisierung erhält, während die Weitergabe eines Schreibvorgangs für dieses Element aus Region A aussteht, wird die Weitergabe nach dem Prinzip Wer zuletzt schreibt, gewinnt unterdrückt. Jede Aktualisierung in Region B kann eine eingehende Schreibanforderung unterdrücken.

Beim Modus Schreiben in eine beliebige Region können Lese- und Schreibvorgänge in Region B fortgesetzt werden. Dabei wird darauf vertraut, dass die Elemente in Region A irgendwann in Region B übertragen werden, und es wird anerkannt, dass möglicherweise Elemente fehlen, bis Region A wieder online ist. Wenn möglich, beispielsweise bei idempotenten Schreibvorgängen, sollten Sie erwägen, den aktuellen Schreibverkehr wiederzugeben (z. B. durch die Verwendung einer vorgeschalteten Ereignisquelle), um die Lücke möglicherweise fehlender Schreibvorgänge zu schließen und die Konfliktlösung „Wer zuletzt schreibt, gewinnt“ die letztendliche Weiterleitung des eingehenden Schreibvorgangs unterdrücken zu lassen.

Bei den anderen Schreibmodi müssen Sie berücksichtigen, inwieweit ein Weiterarbeiten mit einem etwas veralteten Stand möglich ist. Eine kurze Zeitspanne von Schreibvorgängen, wie von ReplicationLatency verfolgt, wird fehlen, bis Region A wieder online ist. Ist ein Vorankommen der Geschäfte möglich? In einigen Fällen ja, in anderen jedoch möglicherweise nicht ohne zusätzliche Mechanismen zur Risikominderung.

Stellen Sie sich zum Beispiel vor, Sie müssen selbst nach einem vollständigen Ausfall der Region ohne Unterbrechung ein verfügbares Guthaben aufrechterhalten. Sie könnten das Guthaben in zwei Posten aufteilen, einen in Region A und einen in Region B, die zunächst jeweils die Hälfte des Guthabens beinhalten. Hierfür würde der Modus Schreiben in Ihre Region verwendet. Transaktionsaktualisierungen, die in jeder Region verarbeitet werden, würden der lokalen Kopie des Guthabens zugeordnet. Wenn Region A vollständig offline geht, könnte die Arbeit mit der Transaktionsverarbeitung in Region B fortgesetzt werden und die Schreibvorgänge wären auf den Teil des Guthabens in Region B beschränkt. Eine solche Aufteilung des Guthabens führt zu Schwierigkeiten, wenn das Guthaben knapp wird oder wieder ausgeglichen werden muss, doch ist dies ein Beispiel für eine sichere Geschäftserholung auch bei unsicheren ausstehenden Schreibvorgängen.

Stellen Sie sich als weiteres Beispiel vor, Sie erfassen Daten aus Webformularen. Sie können Optimistic Concurrency Control (OCC) verwenden, um Datenelementen Versionen zuzuweisen und die neueste Version als verdecktes Feld in das Webformular einzubetten. Bei jedem Absenden ist der Schreibvorgang nur erfolgreich, wenn die Version in der Datenbank immer noch mit der Version übereinstimmt, für die das Formular erstellt wurde. Wenn die Versionen nicht übereinstimmen, kann das Webformular auf der Grundlage der aktuellen Version in der Datenbank aktualisiert (oder sorgfältig zusammengeführt) werden, und der Benutzer kann erneut fortfahren. Das OCC-Modell schützt in der Regel davor, dass ein anderer Client die Daten überschreibt und eine neue Version der Daten erzeugt. Es kann aber auch bei einem Failover hilfreich sein, wenn ein Client auf ältere Datenversionen stößt. Angenommen, Sie verwenden den Zeitstempel als Version. Das Formular wurde um 12:00 Uhr erstmalig für Region A erstellt, versucht aber (nach einem Failover), in Region B zu schreiben, und stellt fest, dass die neueste Version in der Datenbank die Uhrzeit 11:59 aufweist. In diesem Szenario kann der Client entweder warten, bis die Version von 12:00 Uhr an Region B weitergegeben wird, und dann auf diese Version schreiben oder auf 11:59 aufbauend eine neue Version 12:01 erstellen (die nach dem Schreiben die nach Wiederherstellung von Region A eingehende Version unterdrücken würde).

Ein drittes Beispiel: Ein Finanzdienstleistungsunternehmen speichert Daten über Kundenkonten und deren Finanztransaktionen in einer DynamoDB-Datenbank. Bei einem vollständigen Ausfall von Region A sollte das Unternehmen sicherstellen, dass alle Schreibaktivitäten im Zusammenhang mit seinen Konten entweder vollständig in Region B verfügbar sind, oder seine Konten als bekannte Teilkonten unter Quarantäne stellen, bis Region A wieder online ist. Anstatt den gesamten Geschäftsverkehr zu unterbrechen, entschied sich das Unternehmen dafür, die Geschäftstätigkeit nur für den winzigen Bruchteil der Konten auszusetzen, bei denen nicht weitergeleitete Transaktionen festgestellt wurden. Um dies zu erreichen, wurde eine dritte Region verwendet, die wir Region C nennen wollen. Vor der Verarbeitung von Schreibvorgänge in Region A stellte das Unternehmen eine kurze Zusammenfassung dieser ausstehenden Vorgänge (z. B. eine neue Transaktionsanzahl für ein Konto) in Region C. Diese Zusammenfassung reichte für Region B aus, um festzustellen, ob ihre Ansicht vollständig aktuell war. Durch diese Maßnahme wurde das Konto ab dem Zeitpunkt des Schreibens in Region C praktisch gesperrt, bis Region A die Schreibvorgänge akzeptierte und Region B sie erhielt. Die Daten in Region C wurden nur im Rahmen eines Failovers verwendet, nach dem Region B ihre Daten mit Region C abgleichen und so feststellen konnte, ob einige ihrer Konten veraltet waren. Diese Konten wurden als unter Quarantäne gestellt, bis im Zuge der Wiederherstellung von Region A die Teildaten an Region B weitergegeben wurden. Falls Region C ausfallen würde, könnte stattdessen eine neue Region D zur Verwendung eingerichtet werden. Die Daten in Region C sind sehr transient und nach wenigen Minuten würde Region D über eine Aufzeichnung der in Übertragung befindlichen Schreibvorgänge verfügen, die aktuell genug ist, um wirklich nützlich zu sein. Sollte es zu einem Ausfall von Region B kommen, könnte Region A in Kooperation mit Region C, weiterhin Schreibanforderungen annehmen. Das Unternehmen war bereit, Schreibvorgänge mit höherer Latenz zu akzeptieren (in zwei Regionen: C und dann A), und verfügte glücklicherweise über ein Datenmodell, bei dem der Status eines Kontos knapp zusammengefasst werden konnte.