Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Evakuierung einer Region mit globalen Tabellen
Beim Evakuieren einer Region werden Lese- und Schreibaktivitäten aus dieser Region verlagert. Meistens handelt es sich hier um Schreibaktivitäten, manchmal auch um Leseaktivitäten.
Evakuierung einer Live-Region
Sie könnten sich aus verschiedenen Gründen dafür entscheiden, eine Live-Region zu evakuieren. Die Evakuierung kann Teil der üblichen Geschäftsaktivität sein, z. B. wenn Sie den Modus „In eine Region follow-the-sun schreiben“ verwenden. Die Evakuierung könnte auch auf eine geschäftliche Entscheidung zurückzuführen sein, die derzeit aktive Region zu ändern, da es Fehler im Software-Stack außerhalb von DynamoDB gegeben hat oder allgemeine Probleme wie höhere Latenzen als üblich innerhalb der Region festgestellt wurden.
Mit dem Modus Schreiben in eine beliebige Region ist es ganz einfach, eine Live-Region zu evakuieren. Sie können den Datenverkehr über ein beliebiges Weiterleitungssystem an die alternativen Regionen weiterleiten und die Schreibvorgänge, die bereits in der evakuierten Region stattgefunden haben, wie gewohnt replizieren lassen.
Bei den Modi Schreiben in eine Region und Schreiben in Ihre Region müssen Sie sicherstellen, dass alle Schreibvorgänge in die aktive Region vollständig aufgezeichnet, als Stream verarbeitet und global weitergegeben wurden, bevor Sie mit Schreibvorgängen in die neue aktive Region beginnen. Dies ist notwendig, um sicherzustellen, dass für zukünftige Schreibvorgänge die neueste Version der Daten verwendet wird.
Angenommen, Region A ist aktiv und Region B passiv (entweder für die vollständige Tabelle oder für Elemente in Region A). Der typische Evakuierungsmechanismus besteht darin, Schreiboperationen in A anzuhalten, lange genug zu warten, bis diese Operationen vollständig an B weitergegeben wurden, den Architektur-Stack zu aktualisieren, um B als aktiv zu erkennen, und dann die Schreiboperationen auf B fortzusetzen. Es gibt keine Metrik, die mit absoluter Sicherheit anzeigt, dass Region A ihre Daten vollständig in Region B repliziert hat. Wenn Region A fehlerfrei ist, reicht es in der Regel aus, Schreiboperationen in Region A anzuhalten und 10-mal den aktuellen Maximalwert der Metrik ReplicationLatency abzuwarten, um festzustellen, dass die Replikation abgeschlossen ist. Wenn Region A fehlerhaft ist und andere Bereiche mit erhöhten Latenzen aufweist, würden Sie als Wartezeit ein größeres Vielfaches des Maximalwertes wählen.
Evakuierung einer Offline-Region
Ein Sonderfall ist zu berücksichtigen: Was wäre, wenn Region A ohne vorherige Ankündigung vollständig offline gehen würde? Dies ist äußerst unwahrscheinlich, doch es ist dennoch ratsam, dies in Betracht zu ziehen. In diesem Fall werden alle Schreibvorgänge in Region A, die noch nicht weitergegeben wurden, gespeichert und weitergegeben, nachdem Region A wieder online ist. Die Schreiboperationen 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, 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 die Arbeit mit einem leichten out-of-date Blick auf die Welt fortgesetzt werden kann. 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 auch nach einem 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 letztes Beispiel: Ein Finanzdienstleistungsunternehmen speichert Daten über Kundenkonten und deren Finanztransaktionen in einer DynamoDB-Datenbank. Bei einem vollständigen Ausfall von Region A wollte das Unternehmen sicherstellen, dass alle Schreibaktivitäten im Zusammenhang mit seinen Konten entweder vollständig in Region B verfügbar waren, oder es wollte seine Konten als bekannte partielle Konten unter Quarantäne stellen, bis Region A wieder online war. 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 Schreiboperationen in Region A stellte das Unternehmen eine kurze Zusammenfassung dieser ausstehenden Operationen (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 markiert, 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 waren sehr flüchtig, und nach ein paar Minuten verfügte Region D über ausreichend up-to-date Aufzeichnungen der Schreibvorgänge während des Fluges, um sie in vollem Umfang nutzen zu können. 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.
