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. # Verwenden von globalen Tabellen in DynamoDB Globale Tabellen bauen auf der globalen Reichweite von Amazon DynamoDB auf, um Ihnen eine vollständig verwaltete, multiregionale und multiaktive Datenbank zur Verfügung zu stellen, die schnelle lokale Lese- und Schreibleistung für massiv skalierte, globale Anwendungen bietet. Globale Tabellen replizieren Ihre DynamoDB-Tabellen automatisch in die von Ihnen ausgewählten. AWS-Regionen Es sind keine Änderungen an der Anwendung erforderlich, da globale Tabellen vorhandene DynamoDB APIs verwenden. Für die Verwendung von globalen Tabellen fallen keine Vorabkosten an und Sie müssen keine Verpflichtungen im Voraus eingehen. Sie zahlen nur für die tatsächlich genutzten Ressourcen. Dieser Leitfaden erklärt, wie Sie globale DynamoDB-Tabellen effektiv nutzen können. Er enthält die wichtigsten Fakten über globale Tabellen, erklärt die wichtigsten Anwendungsfälle der Funktion, beschreibt die zwei Konsistenzmodi, stellt eine Systematik mit drei verschiedenen Schreibmodellen vor, die Sie in Betracht ziehen sollten, geht die vier wichtigsten Optionen für die Weiterleitung von Anforderungen durch, die Sie implementieren können, erörtert Möglichkeiten zur Evakuierung einer Region, die live ist, oder einer Region, die offline ist, erklärt, wie Sie über die Planung von Durchsatzkapazitäten nachdenken sollten, und enthält eine Checkliste mit Dingen, die Sie bei der Implementierung globaler Tabellen berücksichtigen sollten. [Dieses Handbuch fügt sich in einen größeren Kontext von Bereitstellungen in AWS mehreren Regionen ein, wie im Whitepaper [Grundlagen AWS mehrerer Regionen und in den Entwurfsmustern](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) für Datenstabilität mit Video beschrieben. AWS](https://www.youtube.com/watch?v=7IA48SOX20c) **Topics** + [Wichtige Fakten zum Design von globalen DynamoDB-Tabellen](#bp-global-table-design.prescriptive-guidance.facts) + [Wichtige Fakten zu MREC](#bp-global-table-design-MREC-facts) + [Wichtige Fakten zu MRSC](#bp-global-table-design-MRSC-facts) + [Anwendungsfälle für globale MREC-Tabellen in DynamoDB](#bp-global-table-design.prescriptive-guidance.usecases) + [Schreibmodi bei Verwendung von globalen DynamoDB-Tabellen](bp-global-table-design.prescriptive-guidance.writemodes.md) + [Routing-Strategien in DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) + [Evakuierungsprozesse](bp-global-table-design.prescriptive-guidance.evacuation.md) + [Planung der Durchsatzkapazität für globale DynamoDB-Tabellen](bp-global-table-design.prescriptive-guidance.throughput.md) + [Checkliste zur Vorbereitung für globale DynamoDB-Tabellen](bp-global-table-design.prescriptive-guidance.checklist-and-faq.md) + [Fazit und Ressourcen](#bp-global-table-design.prescriptive-guidance-resources-conclusion) ## Wichtige Fakten zum Design von globalen DynamoDB-Tabellen + Es gibt zwei Versionen globaler Tabellen: die aktuelle Version [Global Tables Version 2019.11.21 (Current)](GlobalTables.md) (manchmal als „V2“ bezeichnet) und [Version 2017.11.29 (Legacy) der globalen Tabellen](globaltables.V1.md) (manchmal als „V1“ bezeichnet). In diesem Leitfaden geht es ausschließlich um die aktuelle Version. + DynamoDB (ohne globale Tabellen) ist ein regionaler Service, was bedeutet, dass er hochgradig verfügbar und intrinsisch widerstandsfähig gegenüber Infrastrukturausfällen, einschließlich des Ausfalls einer gesamten Availability Zone. Eine DynamoDB-Tabelle für eine einzelne Region ist für eine Verfügbarkeit von 99,99 % konzipiert. Weitere Informationen finden Sie unter [DynamoDB – Service Level Agreement (SLA)](https://aws.amazon.com/dynamodb/sla/). + Eine globale DynamoDB-Tabelle repliziert ihre Daten zwischen zwei oder mehr Regionen. Eine DynamoDB-Tabelle für mehrere Regionen ist für eine Verfügbarkeit von 99,999 % konzipiert. Bei richtiger Planung kann mithilfe von globalen Tabellen eine Architektur geschaffen werden, die regionalen Ausfällen standhält. + In DynamoDB gibt es keinen globalen Endpunkt. Alle Anforderungen werden an einen regionalen Endpunkt gestellt, der auf die für diese Region lokale Instance der globalen Tabelle zugreift. + Aufrufe an DynamoDB sollten nicht regionsübergreifend erfolgen. Als bewährte Methode sollte eine Anwendung, die sich in einer Region befindet, nur auf den lokalen DynamoDB-Endpunkt für diese Region direkt zugreifen. Wenn innerhalb einer Region (auf der DynamoDB-Ebene oder im umgebenden Stack) Probleme festgestellt werden, sollte der Endbenutzer-Datenverkehr an einen anderen Anwendungsendpunkt weitergeleitet werden, der in einer anderen Region gehostet wird. Globale Tabellen stellen sicher, dass Anwendung in jeder Region Zugriff auf dieselben Daten hat. ### Konsistenzmodi Sie können bei der Erstellung einer globalen Tabelle den Konsistenzmodus konfigurieren. Globale Tabellen unterstützen zwei Konsistenzmodi: Multi-Region Eventual Consistency (MREC) und Multi-Region Strong Consistency (MRSC), der im Juni 2025 eingeführt wurde. Wenn Sie beim Erstellen einer globalen Tabelle keinen Konsistenzmodus angeben, wird für die globale Tabelle standardmäßig MREC verwendet. Replikate, die mit unterschiedlichen Konsistenzmodi konfiguriert wurden, sind in einer globalen Tabelle nicht zulässig. Sie können den Konsistenzmodus einer globalen Tabelle nach der Erstellung nicht mehr ändern. ## Wichtige Fakten zu MREC + Globale Tabellen, die MRSC verwenden, nutzen auch ein Aktiv-Aktiv-Replikationsmodell. Aus Sicht von DynamoDB ist die Tabelle in jeder Region gleichberechtigt, Lese- und Schreibanforderungen anzunehmen. Nach Erhalt einer Schreibanforderung repliziert die lokale Replikattabelle den Schreibvorgang im Hintergrund in andere teilnehmende Remote-Regionen. + Elemente werden einzeln repliziert. Elemente, die im Rahmen einer einzelnen Transaktion aktualisiert wurden, können möglicherweise nicht zusammen repliziert werden. + Jede Tabellenpartition in der Quellregion repliziert ihre Schreibvorgänge parallel zu allen anderen Partitionen. Die Reihenfolge der Schreibvorgänge innerhalb einer Remote-Region entspricht möglicherweise nicht der Reihenfolge der Schreibvorgänge in der Quellregion. Weitere Informationen zu Tabellenpartitionen finden Sie im Blogbeitrag [Skalierung von DynamoDB: Wie sich Partitionen, Hotkeys und Split for Heat auf die Leistung auswirken](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/). + Ein neu geschriebenes Element wird in der Regel innerhalb einer Sekunde auf alle Replikattabellen verteilt. Die Verteilung in nahegelegene Regionen erfolgt tendenziell schneller. + Amazon CloudWatch stellt für jedes Regionspaar eine `ReplicationLatency` Metrik bereit. Zur Berechnung dieser Metrik wird die Ankunftszeit eingehender Elemente mit der Zeit verglichen, zu der sie ursprünglich geschrieben wurden, und ein Durchschnitt ermittelt. Die Zeitangaben werden innerhalb CloudWatch der Quellregion gespeichert. Der Vergleich der durchschnittlichen und maximalen Zeiten kann hilfreich sein, um die durchschnittliche und die stärkste Replikationsverzögerung zu ermitteln. Für diese Latenz gibt es kein SLA. + Wenn ein einzelnes Element ungefähr zu derselben Zeit (innerhalb dieses `ReplicationLatency`-Fensters) in zwei verschiedenen Regionen aktualisiert wird und der zweite Schreibvorgang vor der Replikation des ersten Schreibvorgangs stattfindet, kann es zu Schreibkonflikten kommen. Globale Tabellen, die MREC verwenden, lösen solche Konflikte nach dem Prinzip „Wer zuletzt schreibt, gewinnt“, basierend auf dem Zeitstempel der Schreibvorgänge. Der erste Vorgang „verliert“ gegen den zweiten Vorgang. Diese Konflikte werden nicht in CloudWatch oder AWS CloudTrail aufgezeichnet. + Jedes Element verfügt über einen Zeitstempel für den letzten Schreibvorgang, der als private Systemeigenschaft gespeichert wird. Zur Umsetzung des Prinzips „Wer zuletzt schreibt, gewinnt“ wird ein bedingter Schreibvorgang verwendet, der voraussetzt, dass der Zeitstempel des eingehenden Elements größer als der Zeitstempel des vorhandenen Elements ist. + In einer globalen Tabelle werden alle Elemente in alle teilnehmenden Regionen repliziert. Wenn Sie unterschiedliche Replikationsbereiche haben möchten, können Sie mehrere globale Tabellen erstellen und jeder Tabelle verschiedene teilnehmende Regionen zuweisen. + Die lokale Region akzeptiert Schreibvorgänge auch dann, wenn die Replikatregion offline ist oder die `ReplicationLatency` wächst. Die lokale Tabelle versucht weiterhin, Elemente in die Remote-Tabelle zu replizieren, bis dies für jedes Element erfolgreich ist. + Sollte eine Region vollständig offline gehen, was sehr unwahrscheinlich ist, werden alle ausstehenden ausgehenden und eingehenden Replikationen erneut versucht, wenn sie später wieder online ist. Es sind keine besonderen Maßnahmen erforderlich, um die Tabellen wieder zu synchronisieren. Das Prinzip *Wer zuletzt schreibt, gewinnt*, stellt sicher, dass die Daten letztendlich konsistent werden. + Sie können einer DynamoDB-MREC-Tabelle jederzeit eine neue Region hinzufügen. DynamoDB kümmert sich um die erste Synchronisierung und die fortlaufende Replikation. Sie können eine Region (selbst die ursprüngliche Region) auch entfernen. Dadurch wird die lokale Tabelle in dieser Region gelöscht. ## Wichtige Fakten zu MRSC + Globale Tabellen, die MRSC verwenden, nutzen auch ein Aktiv-Aktiv-Replikationsmodell. Aus Sicht von DynamoDB ist die Tabelle in jeder Region gleichberechtigt, Lese- und Schreibanforderungen anzunehmen. Elementänderungen im Replikat einer globalen MRSC-Tabelle werden **synchron** in mindestens eine andere Region repliziert, bevor der Schreibvorgang eine erfolgreiche Antwort zurückgibt. + Strikt konsistente Lesevorgänge für ein beliebiges MRSC-Replikat geben immer die neueste Version eines Elements zurück. Bei bedingten Schreibvorgängen wird immer der Bedingungsausdruck mit der aktuellen Version des Elements verglichen. Aktualisierungen beziehen sich immer auf die neueste Version eines Elements. + Letztendlich konsistente Lesevorgänge für ein MRSC-Replikat schließen möglicherweise keine Änderungen ein, die kürzlich in einer anderen Region vorgenommen wurden, und möglicherweise nicht einmal Änderungen, die erst vor ganz Kurzem in derselben Region durchgeführt wurden. + Ein Schreibvorgang schlägt mir der Ausnahme `ReplicatedWriteConflictException` fehl, wenn versucht wird, ein Element zu ändern, das bereits in einer anderen Region geändert wird. Schreibvorgänge, bei denen die Ausnahme `ReplicatedWriteConflictException` auftritt, können wiederholt werden und sind erfolgreich, wenn das Element in einer anderen Region nicht mehr geändert wird. + Mit MRSC sind die Latenzen bei Schreibvorgängen und bei strikt konsistenten Lesevorgängen höher. Diese Vorgänge erfordern eine regionsübergreifende Kommunikation. Diese Kommunikation mehr Latenz mit sich bringen, die sich je nach der Round-Trip-Latenz zwischen der Region, auf die zugegriffen wird, und der nächstgelegenen Region, die in der globalen Tabelle aufgeführt ist, erhöht. Weitere Informationen finden Sie in der AWS re:Invent 2024-Präsentation [Multi-Region strong consistency with DynamoDB global tables](https://www.youtube.com/watch?v=R-nTs8ZD8mA). Bei letztendlich konsistenten Lesevorgängen gibt es keine zusätzliche Latenz. Sie können diese Latenzen in Ihren Regionen mit einem Open-Source-[Testtool](https://github.com/awslabs/amazon-dynamodb-tools/tree/main/tester) berechnen. + Elemente werden einzeln repliziert. Globale Tabellen, die MRSC verwenden, unterstützen die Transaktion nicht. APIs + Eine globale MRSC-Tabelle muss in genau drei Regionen bereitgestellt werden. Sie können eine globale MRSC-Tabelle mit drei Replikaten oder zwei Replikaten und einem Witness konfigurieren. Ein Witness ist eine Komponente einer globalen MRSC-Tabelle, die aktuelle Daten enthält, die in Replikate der globalen Tabelle geschrieben wurden. Ein Witness bietet eine optionale Alternative zu einem vollständigen Replikat und unterstützt gleichzeitig die Verfügbarkeitsarchitektur von MRSC. Sie können für einen Witness keine Lese- oder Schreibvorgänge ausführen. Für einen Witness fallen keine Speicher- oder Schreibkosten an. Ein Witness befindet sich in einer anderen Region als die beiden Replikate. + Sie erstellen eine globale MRSC-Tabelle, indem Sie einer vorhandenen DynamoDB-Tabelle, die keine Daten enthält, ein Replikat und einen Witness oder zwei Replikate hinzufügen. Sie können einer vorhandenen globalen MRSC-Tabelle keine zusätzlichen Replikate hinzufügen. Ein einzelnes Replikat oder ein Witness kann nicht aus einer globalen MRSC-Tabelle gelöscht werden. Sie können zwei Replikate oder ein Replikat und einen Witness aus einer globalen MRSC-Tabelle löschen. Im zweiten Szenario wird das verbleibende Replikat in eine DynamoDB-Tabelle mit einer einzelnen Region konvertiert. + Sie können anhand der API-Ausgabe ermitteln, ob für eine globale MRSC-Tabelle ein Zeuge konfiguriert ist und in welcher Region er konfiguriert ist. DescribeTable Der Zeuge gehört DynamoDB und wird von diesem verwaltet. Er erscheint nicht in Ihrer Region, AWS-Konto in der er konfiguriert ist. + Die globalen MRSC-Tabellen sind in den folgenden Region-Sets verfügbar: + Region-Set USA: USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Oregon) + Region-Set Europa: Europa (Frankfurt), Europa (Irland), Europa (London), Europa (Paris) + Region-Set Asien-Pazifik: Asien-Pazifik (Tokio), Asien-Pazifik (Seoul) und Asien-Pazifik (Osaka). + Globale MRSC-Tabellen können sich nicht über Region-Sets erstrecken. Beispielsweise kann eine globale MRSC-Tabelle keine Replikate aus Region-Sets der USA und der EU enthalten. + Die Funktion „Time to Live“ (TTL) wird von globalen MRSC-Tabellen nicht unterstützt. + Lokale sekundäre Indizes (LSIs) werden für globale MRSC-Tabellen nicht unterstützt. + CloudWatch Contributor Insights-Informationen werden nur für die Region gemeldet, in der ein Vorgang stattgefunden hat. + Die lokale Region akzeptiert alle Lese- und Schreibvorgänge, solange es eine zweite Region gibt, in der ein Replikat oder ein Witness gehostet wird, um das Quorum einzurichten. Wenn keine zweite Region verfügbar ist, kann die lokale Region nur letztendlich konsistente Lesevorgänge verarbeiten. + Im unwahrscheinlichen Fall, dass eine Region vollständig offline geht, holt sie automatisch auf, wenn sie später wieder online ist. Solange der Vorgang nicht abgeschlossen ist, geben Schreibvorgänge und stark konsistente Lesevorgänge *nur* in der Region, in der der Vorgang stattfindet, Fehler zurück, während Anfragen an andere Regionen weiterhin normal ausgeführt werden. Schließlich werden bei konsistenten Lesevorgängen in die aufholende Region die Daten zurückgegeben, die bisher in die Region übertragen wurden, und zwar mit dem üblichen lokalen Konsistenzverhalten zwischen dem Leader-Knoten und den lokalen Replikaten. Es sind keine besonderen Maßnahmen erforderlich, um die Tabellen wieder zu synchronisieren. ## Anwendungsfälle für globale MREC-Tabellen in DynamoDB Globale MREC-Tabellen bieten folgende Vorteile: + **Lesevorgänge mit niedrigerer Latenz.** Platzieren Sie eine Kopie der Daten näher am Endbenutzer, um die Netzwerklatenz bei Lesevorgängen zu reduzieren. Die Daten werden so aktuell gehalten wie der `ReplicationLatency`-Wert. + **Schreibvorgänge mit niedrigerer Latenz.** Sie können in eine nahegelegene Region schreiben, um die Netzwerklatenz und die für den Schreibvorgang benötigte Zeit zu reduzieren. Der Schreibverkehr muss sorgfältig weitergeleitet werden, um Konflikte zu vermeiden. Die Methoden für die Weiterleitung werden unter [Routing-Strategien in DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) ausführlicher erörtert. + **Nahtlose Migration von Regionen.** Sie können eine neue Region hinzufügen und die alte Region löschen, um eine Bereitstellung ohne Ausfallzeit auf der Datenebene von einer Region zu einer anderen zu migrieren. Die globalen MREC- und MRSC-Tabellen bieten beide den folgenden Vorteil: + **Verbesserte Resilienz und Notfallwiederherstellung.** Wenn es in einer Region zu Leistungseinbußen oder einem vollständigen Ausfall kommt, können Sie diese evakuieren. Evakuieren bedeutet, einige oder alle Anforderungen, die in dieser Region eingehen, zu verschieben. Durch die Verwendung von globalen Tabellen erhöht sich das [DynamoDB-SLA](https://aws.amazon.com/dynamodb/sla/) für den monatlichen Prozentsatz der Betriebszeit von 99,99 % auf 99,999 %. Die Verwendung von MREC unterstützt einen Recovery Point Objective (RPO) und einen Recovery Time Objective (RTO), die in Sekunden gemessen werden. Bei Verwendung von MRSC wird ein RPO von Null unterstützt. Zum Beispiel präsentierte Fidelity Investments auf der re:Invent 2022, wie das Unternehmen globale DynamoDB-Tabellen für sein Auftragsverwaltungssystem verwendet. Ziel war es, eine zuverlässige Verarbeitung mit geringer Latenz in einem Umfang zu erzielen, der mit einer On-Premises-Verarbeitung nicht möglich wäre, dabei aber gleichzeitig die Resilienz gegenüber Ausfällen der Availability Zone und Regionen aufrechtzuerhalten. Wenn Ihr Ziel Resilienz und Notfallwiederherstellung ist, weisen MRSC-Tabellen zwar höhere Latenzen bei Schreibvorgängen und strikt konsistenten Lesevorgängen auf, unterstützen aber einen RPO von Null. Globale MREC-Tabellen können einen RPO unterstützen, der der verzögerten Replikation zwischen Replikaten entspricht, die je nach Region in der Regel einige Sekunden beträgt. # Schreibmodi bei Verwendung von globalen DynamoDB-Tabellen Globale Tabellen sind auf Tabellenebene immer aktiv-aktiv. Vielleicht möchten Sie sie insbesondere bei MREC-Tabellen jedoch als aktiv-passiv behandeln, indem Sie steuern, wie Schreibanforderungen weitergeleitet werden. Sie könnten sich beispielsweise dafür entscheiden, Schreibanforderungen an eine einzelne Region weiterzuleiten, um mögliche Schreibkonflikte zu vermeiden, die bei MREC-Tabellen vorkommen können. Es gibt drei Hauptmuster für verwaltete Schreibvorgänge, die in den nächsten drei Abschnitten erläutert werden. Sie sollten überlegen, welches Schreibmuster zu Ihrem Anwendungsfall passt. Diese Wahl wirkt sich auf die Weiterleitung von Anforderungen, die Evakuierung einer Region und die Notfallwiederherstellung aus. Die Anleitung in späteren Abschnitten hängt vom Schreibmodus Ihrer Anwendung ab. ## Modus „Schreiben in eine beliebige Region“ (keine Primärregion) Der Modus *Schreiben in eine beliebige Region*, der im folgenden Diagramm dargestellt wird, ist vollständig aktiv-aktiv. In diesem Modus bestehen keine Einschränkungen in Bezug darauf, wo ein Schreibvorgang stattfinden kann. Jede Region kann jederzeit Schreibvorgänge akzeptieren. Dies ist der einfachste Modus, der jedoch nur für einige Arten von Anwendungen verwendet werden kann. Dieser Modus ist für alle MRSC-Tabellen geeignet. Er eignet sich auch für MREC-Tabellen, wenn alle Writer idempotent und daher sicher wiederholbar sind, sodass gleichzeitige oder wiederholte Schreibvorgänge in verschiedenen Regionen nicht miteinander in Konflikt geraten. Er kann beispielsweise verwendet werden, wenn ein Benutzer seine Kontaktdaten aktualisiert. Dieser Modus eignet sich auch gut für einen Sonderfall der Idempotenz, einen Append-Only-Datensatz, bei dem alle Schreibvorgänge eindeutige Einfügungen unter einem deterministischen Primärschlüssel sind. Schließlich ist dieser Modus für MREC geeignet, wenn das Risiko von Schreibkonflikten akzeptabel wäre. ![\[Diagramm, das die Funktionsweise von Client-Schreibvorgängen in eine beliebige Region zeigt.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/gt-client-read-write-to-any-region2.png) Der Modus *Schreiben in eine beliebige Region* ist die am einfachsten zu implementierende Architektur. Die Weiterleitung ist einfacher, da jede Region jederzeit Schreibziel sein kann. Ein Failover ist einfacher, da bei MRSC-Tabellen die Elemente immer synchronisiert werden. Außerdem können bei MRSC-Tabellen alle kürzlichen Schreibvorgänge beliebig oft in jeder sekundären Region wiederholt werden. Wenn möglich, sollten Sie diesen Schreibmodus vorsehen. Mehrere Video-Streaming-Services verwenden beispielsweise häufig globale Tabellen, um Lesezeichen, Bewertungen, Ansehstatus-Flags usw. zu verfolgen. Diese Bereitstellungen nutzen MREC-Tabellen, da sie Replikate benötigen, die auf der ganzen Welt verstreut sind, wobei jedes Replikat Lese- und Schreibvorgänge mit niedriger Latenz ermöglicht. Für diese Bereitstellungen kann der Modus *Schreiben in eine beliebige Region* verwendet werden, solange sichergestellt wird, dass jeder Schreibvorgang idempotent ist. Dies ist der Fall, wenn bei jeder Aktualisierung – beispielsweise beim Festlegen eines neuen aktuellen Zeitcodes, beim Zuweisen einer neuen Überprüfung oder beim Einstellen eines neuen Ansehstatus – der neue Status des Benutzers direkt zugewiesen wird und der nächste korrekte Wert für ein Element nicht von seinem aktuellen Wert abhängt. Wenn die Schreibanforderungen des Benutzers zufälligerweise an verschiedene Regionen weitergeleitet werden, bleibt der letzte Schreibvorgang bestehen und der globale Status wird gemäß der letzten Zuweisung festgelegt. Lesevorgänge in diesem Modus werden letztendlich konsistent, verzögert um den letzten `ReplicationLatency`-Wert. In einem anderen Beispiel verwendet ein Finanzdienstleistungsunternehmen globale Tabellen als Teil eines Systems, um eine laufende Aufstellung der Debitkartenkäufe für jeden Kunden zu führen und die Cashback-Prämien des Kunden zu berechnen. Das Unternehmen möchte ein `RunningBalance`-Element pro Kunde beibehalten. Dieser Schreibmodus ist naturgemäß nicht idempotent, da beim Eingehen von Transaktionen der Saldo mit einem `ADD`-Ausdruck geändert wird, bei dem der neue korrekte Wert vom aktuellen Wert abhängt. Durch die Verwendung von MRSC-Tabellen kann das Unternehmen *in eine beliebige Region schreiben*, da jeder `ADD`-Aufruf immer mit dem allerneuesten Wert des Elements ausgeführt wird. Ein drittes Beispiel betrifft ein Unternehmen, das Online-Werbeplatzierungsdienste anbietet. Dieses Unternehmen hat entschieden, dass ein geringes Risiko eines Datenverlusts akzeptabel wäre, um die Designvereinfachungen des Modus *Schreiben in eine beliebige Region* zu erreichen. Wenn Anzeigen geschaltet werden, bleiben nur wenige Millisekunden Zeit, um genügend Metadaten abzurufen, zu bestimmen, welche Anzeige geschaltet werden soll, und dann die Ad Impression aufzuzeichnen, damit dem betreffenden Benutzer nicht mehrmals dieselbe Anzeige präsentiert wird. Mit globalen Tabellen kann das Unternehmen sowohl Lesevorgänge mit niedriger Latenz für Endbenutzer auf der ganzen Welt als auch Schreibvorgänge mit niedriger Latenz erzielen. Alle Ad Impressions für einen Benutzer können in einem einzelnen Element aufgezeichnet werden, das als wachsende Liste dargestellt wird. Das Unternehmen verwendet ein Element, anstatt Elemente an eine Elementauflistung anzuhängen, da auf diese Weise ältere Ad Impressions im Rahmen jedes Schreibvorgangs entfernt werden können, ohne Kosten für einen Löschvorgang zu verursachen. Dieser Schreibvorgang ist nicht idempotent. Wenn derselbe Endbenutzer Anzeigen aus mehreren Regionen ungefähr zur gleichen Zeit sieht, besteht die Möglichkeit, dass ein Schreibvorgang für eine Ad Impression den anderen überschreibt. Das Risiko besteht darin, dass ein Benutzer eine Anzeige gelegentlich wiederholt sieht. Das Unternehmen hat entschieden, dass dies akzeptabel ist. ## Schreiben in eine Region (einzelne Primärregion) Der Modus *Schreiben in eine Region*, der im folgenden Diagramm dargestellt wird, ist aktiv-passiv. Alle Schreibvorgänge in der Tabelle werden an eine einzelne aktive Region weitergeleitet. Beachten Sie, dass DynamoDB das Konzept einer einzelnen aktiven Region nicht kennt. Die Anwendungsweiterleitung außerhalb von DynamoDB verwaltet dies. Der Modus *Schreiben in eine Region* ist gut für MREC-Tabellen geeignet, bei denen Schreibkonflikte vermieden werden müssen, indem sichergestellt wird, dass Schreibvorgänge jeweils nur in eine Region gelangen. Dieser Schreibmodus ist hilfreich, wenn Sie bedingte Ausdrücke verwenden möchten und MRSC aus irgendeinem Grund nicht verwenden können, oder wenn Sie Transaktionen ausführen müssen. Diese Ausdrücke sind nur möglich, wenn Sie wissen, dass Sie mit den neuesten Daten arbeiten. Deshalb müssen alle Schreibanforderungen an eine einzelne Region gesendet werden, die über die neuesten Daten verfügt. Wenn Sie eine MRSC-Tabelle verwenden, sollten Sie der Einfachheit halber vielleicht entscheiden, generell in eine Region schreiben. Das kann beispielsweise dazu beitragen, den Ausbau Ihrer Infrastruktur über DynamoDB hinaus zu minimieren. Der Schreibmodus wäre immer noch das Schreiben in eine beliebige Region, da Sie mit MRSC jederzeit sicher in jede Region schreiben könnten, ohne sich Gedanken über die Konfliktlösung machen zu müssen, die dazu führen würde, dass MREC-Tabellen *in eine Region schreiben*. Letztendlich konsistente Lesevorgänge können an alle Replikatregionen geleitet werden, um geringere Latenzen zu erreichen. Strikt konsistente Lesevorgänge müssen an die einzelne Primärregion geleitet werden. ![\[Diagramm, das die Vorgehensweise zum Schreiben in eine Region zeigt.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/gt-client-writes-one-region2.png) Manchmal ist es infolge eines Regionsausfalls notwendig, die aktive Region zu ändern. Manche Benutzer ändern die derzeit aktive Region nach einem regelmäßigen Zeitplan, z. B. bei der Implementierung einer follow-the-sun Bereitstellung. Dadurch wird die aktive Region in der Nähe der Region mit der höchsten Aktivität platziert (normalerweise dort, wo es Tag ist, daher der Name), was zu Lese- und Schreibvorgängen mit der niedrigsten Latenz führt. Ein Nebeneffekt dabei ist, dass der Code zum Ändern der Region täglich aufgerufen wird und damit vor einer Notfallwiederherstellung gründlich getestet wurde. Die passive(n) Region(en) kann/können eine verkleinerte Infrastruktur rund um DynamoDB beibehalten, die nur dann aufgebaut wird, wenn sie zur aktiven Region wird. In diesem Handbuch werden die Designs Pilot Light und Warm Standby nicht behandelt. Weitere Informationen finden Sie unter [Disaster Recovery (DR) -Architektur unter AWS, Teil III: Pilot Light und Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Der Modus *Schreiben in eine Region* ist gut geeignet, wenn Sie globale Tabellen für global verteilte Lesevorgänge mit niedriger Latenz verwenden. Ein Beispiel ist ein großes Social-Media-Unternehmen, das in allen Regionen der Welt dieselben Referenzdaten zur Verfügung haben muss. Das Unternehmen aktualisiert die Daten nicht oft, aber wenn eine Aktualisierung durchgeführt wird, werden die Daten nur in eine Region geschrieben, um mögliche Schreibkonflikte zu vermeiden. Lesevorgänge sind immer von jeder Region aus zulässig. Ein weiteres Beispiel ist das schon erwähnte Finanzdienstleistungsunternehmen, das die tägliche Cashback-Berechnung eingeführt hat. Das Unternehmen nutzte den Modus *Schreiben in eine beliebige Region*, um den Saldo zu berechnen, aber den Modus *Schreiben in eine Region*, um Zahlungen zu verfolgen. Diese Arbeit erfordert Transaktionen, die in MRSC-Tabellen nicht unterstützt werden. Daher funktioniert dieser Prozess besser mit einer separaten MREC-Tabelle und dem Modus *Schreiben in eine Region*. ## Schreiben in Ihre Region (gemischte Primärregion) Der Schreibmodus *Schreiben in Ihre Region*, der im folgenden Diagramm dargestellt ist, kann mit MREC-Tabellen verwendet werden. Er weist verschiedenen Heimatregionen unterschiedliche Datenteilmengen zu und ermöglicht Schreibvorgänge für ein Element nur über dessen Heimatregion. Dieser Modus ist aktiv-passiv, weist jedoch die aktive Region basierend auf dem Element zu. Jede Region ist Primärregion für ihren eigenen, sich nicht überlappenden Datensatz und Schreibvorgänge müssen überwacht werden, um eine korrekte Lokalisierung sicherzustellen. Dieser Modus ist ähnlich wie der Modus *Schreiben in eine Region*, mit der Ausnahme, dass Schreibvorgänge mit geringerer Latenz möglich sind, da die jedem Endbenutzer zugeordneten Daten in größerer Netzwerknähe zu diesem Benutzer platziert werden können. Auch ist die umliegende Infrastruktur gleichmäßiger auf die Regionen verteilt und der Aufbau der Infrastruktur während eines Failover-Szenarios ist weniger aufwendig, da in allen Regionen ein Teil der Infrastruktur bereits aktiv ist. ![\[Diagramm, das die Funktionsweise von Client-Schreibvorgängen für jedes Element in einer einzelnen Region zeigt.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/get-client-writes-each-item-single-region2.png) Sie können die Heimatregion für Elemente auf verschiedene Arten bestimmen: + **Intrinsisch:** Ein bestimmter Aspekt der Daten, z. B. ein spezielles Attribut oder ein Wert, der in den Partitionsschlüssel eingebettet ist, stellt die Heimatregion klar. Diese Technik wird im Blogbeitrag [Verwenden von Region Pinning, um eine Heimatregion für Elemente in einer globalen Amazon-DynamoDB-Tabelle festzulegen](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/) beschrieben. + **Ausgehandelt:** Die Heimatregion jedes Datensatzes wird extern ausgehandelt, z. B. mit einem separaten globalen Dienst, der die Zuweisungen verwaltet. Die Zuweisung kann begrenzt gültig sein. Danach muss sie neu verhandelt werden. + **Tabellenorientiert:** Anstelle einer einzelnen replizierenden globalen Tabelle erstellen Sie genauso viele globale Tabellen wie replizierende Regionen. Der Name jeder Tabelle gibt ihre Heimatregion an. Bei Standardoperationen werden alle Daten in die Heimatregion geschrieben, während andere Regionen eine schreibgeschützte Kopie behalten. Während eines Failovers übernimmt eine andere Region vorübergehend Schreibaufgaben für diese Tabelle. Stellen Sie sich beispielsweise vor, Sie arbeiten für ein Gaming-Unternehmen. Sie benötigen eine niedrige Latenz bei Lese- und Schreibvorgängen für alle Spieler weltweit. Sie weisen jeden Spieler der ihm am nächsten gelegenen Region zu. In dieser Region werden alle Lese- und Schreibvorgänge ausgeführt, sodass eine hohe read-after-write Konsistenz gewährleistet ist. Wenn ein Spieler jedoch verreist oder es in seiner Heimatregion zu einem Ausfall kommt, steht eine vollständige Kopie seiner Daten in anderen Regionen zur Verfügung und der Spieler kann einer anderen Heimatregion zugewiesen werden. Stellen Sie sich als weiteres Beispiel vor, Sie arbeiten in einem Videokonferenzunternehmen. Die Metadaten jeder Konferenz werden einer bestimmten Region zugewiesen. Anrufer können die ihnen am nächsten gelegene Region verwenden, um eine möglichst niedrige Latenz zu erzielen. Wenn eine Region ausfällt, ermöglicht die Verwendung globaler Tabellen eine schnelle Wiederherstellung, da das System die Verarbeitung des Anrufs an eine andere Region weitergeben kann, in der sich bereits eine replizierte Kopie der Daten befindet. **Zusammenfassung** + Der Modus „Schreiben in eine beliebige Region“ eignet sich für MRSC-Tabellen und idempotente Aufrufe von MREC-Tabellen. + Der Modus „Schreiben in eine Region“ eignet sich für idempotente Aufrufe von MREC-Tabellen. + Der Modus „Schreiben in Ihre Region“ eignet sich für nicht-idempotente Aufrufe von MREC-Tabellen, bei denen es wichtig ist, dass Clients in eine Region schreiben, die sich in ihrer Nähe befindet. # Routing-Strategien in DynamoDB Der vielleicht komplexeste Teil der Bereitstellung einer globalen Tabelle ist die Verwaltung der Weiterleitung von Anforderungen. Anforderungen müssen zunächst von einem Endbenutzer an eine Region gesendet werden, die auf irgendeine Weise ausgewählt und weitergeleitet wird. Die Anfrage trifft auf einen Stapel von Diensten in dieser Region, einschließlich einer Rechenschicht, die möglicherweise aus einem Load Balancer besteht, der von einer AWS Lambda Funktion, einem Container oder einem Amazon Elastic Compute Cloud (Amazon EC2) -Knoten unterstützt wird, und möglicherweise auf andere Dienste, einschließlich einer anderen Datenbank. Diese Datenverarbeitungsebene kommuniziert mit DynamoDB. Dazu sollte sie den lokalen Endpunkt für diese Region verwenden. Die Daten in der globalen Tabelle werden in alle anderen teilnehmenden Regionen repliziert und jede Region verfügt über einen ähnlichen Service-Stack rund um ihre DynamoDB-Tabelle. Die globale Tabelle stellt jedem Stack in den verschiedenen Regionen eine lokale Kopie derselben Daten zur Verfügung. Sie könnten einen einzelnen Stack in einer einzelnen Region vorsehen und im Falle eines Problems mit der lokalen DynamoDB-Tabelle Remote-Aufrufe an den DynamoDB-Endpunkt einer sekundären Region einplanen. Dies stellt keine bewährte Methode dar. Wenn in einer Region ein Problem auftritt, das durch DynamoDB verursacht wird (oder, was wahrscheinlicher ist, durch etwas anderes im Stack oder durch einen anderen Service, der von DynamoDB abhängt), ist es am besten, den Endbenutzer zur Verarbeitung in eine andere Region weiterzuleiten und die Datenverarbeitungsebene dieser anderen Region zu verwenden, die mit ihrem lokalen DynamoDB-Endpunkt kommuniziert. Bei diesem Ansatz wird die problematische Region vollständig umgangen. Um Resilienz zu gewährleisten, benötigen Sie eine Replikation über mehrere Regionen hinweg, wobei sowohl die Datenverarbeitungsebene als auch die Datenebene repliziert werden. Es gibt zahlreiche alternative Möglichkeiten, die Anforderung eines Endbenutzers zur Verarbeitung an eine Region weiterzuleiten. Die optimale Option ist von Ihrem Schreibmodus und Ihrer Failover-Strategie abhängig. In diesem Abschnitt werden vier Optionen erörtert: Client-gesteuert, Datenverarbeitungsebene, Route 53 und Global Accelerator. ## Client-gesteuerte Weiterleitung von Anforderungen Bei der clientgesteuerten Weiterleitung von Anfragen, wie im folgenden Diagramm dargestellt, verfolgt der Endbenutzer-Client (eine Anwendung, eine Webseite mit JavaScript oder ein anderer Client) die gültigen Anwendungsendpunkte (z. B. ein Amazon API Gateway Gateway-Endpunkt statt eines wörtlichen DynamoDB-Endpunkts) und verwendet seine eigene eingebettete Logik, um die Region auszuwählen, mit der kommuniziert werden soll. Die Entscheidung kann auf der Grundlage einer zufälligen Auswahl, der niedrigsten beobachteten Latenzen, der höchsten beobachteten Bandbreitenmessung oder lokal durchgeführter Zustandsprüfungen getroffen werden. ![\[Diagramm, das die Funktionsweise von Schreibvorgängen an ein von einem Client ausgewähltes Ziel zeigt.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/gt-routing-is-clients-choice2_v2.png) Ein Vorteil ist, dass sich die Client-gesteuerte Weiterleitung von Anforderungen beispielsweise an die realen Bedingungen des öffentlichen Internetdatenverkehrs anpassen und die Region wechseln kann, falls Leistungseinbußen festgestellt werden. Der Client muss alle potenziellen Endpunkte kennen, doch es kommt nicht oft vor, dass ein neuer regionaler Endpunkt gestartet wird. Beim Modus *Schreiben in eine beliebige Region* kann ein Client einseitig seinen bevorzugten Endpunkt auswählen. Wenn der Zugriff auf eine Region beeinträchtigt ist, kann der Client zu einem anderen Endpunkt weiterleiten. Im Modus *Schreiben in eine Region* benötigt der Client einen Mechanismus, um seine Schreibvorgänge an die aktuell aktive Region weiterzuleiten. Hierfür könnte es ausreichen, empirisch zu testen, welche Region gerade Schreibvorgänge akzeptiert (wobei jede Ablehnung von Schreibvorgängen vermerkt und auf eine Alternative zurückgegriffen wird), oder es muss ein globaler Koordinator aufgerufen werden, um den aktuellen Anwendungsstatus abzufragen (vielleicht auf der Grundlage der Routing-Steuerung von Amazon Application Recovery Controller (ARC), die ein Quorum-gesteuertes System mit 5 Regionen zur Aufrechterhaltung des globalen Zustands für derartige Anforderungen bereitstellt). Der Client kann entscheiden, ob Lesevorgänge für letztendliche Konsistenz in eine beliebige Region weitergeleitet werden können oder ob sie an die aktive Region weitergeleitet werden müssen, um eine starke Konsistenz zu erzielen. Weitere Informationen finden Sie unter [Funktionsweise von Route 53](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html). Im Modus *Schreiben in Ihre Region* muss der Client die Heimatregion für den Datensatz ermitteln, mit dem er arbeitet. Wenn der Client beispielsweise einem Benutzerkonto entspricht und jedes Benutzerkonto einer Region zugeordnet ist, kann der Client den entsprechenden Endpunkt von einem globalen Anmeldesystem anfordern. Ein Finanzdienstleistungsunternehmen beispielsweise, das Benutzer bei der Verwaltung ihrer Geschäftsfinanzen über das Internet unterstützt, könnte globale Tabellen mit dem Modus *Schreiben in Ihre Region* verwenden. Jeder Benutzer muss sich bei einem zentralen Service anmelden. Dieser Service gibt Anmeldeinformationen sowie den Endpunkt für die Region zurück, für den diese Anmeldeinformationen gelten. Die Anmeldeinformationen sind nur kurze Zeit gültig. Danach handelt die Webseite automatisch eine neue Anmeldung aus, was die Gelegenheit bietet, die Aktivitäten des Benutzers möglicherweise in eine neue Region umzuleiten. ## Weiterleitung von Anforderungen auf Datenverarbeitungsebene Bei der Weiterleitung von Anforderungen auf Datenverarbeitungsebene, die im folgenden Diagramm dargestellt ist, entscheidet der auf Datenverarbeitungsebene ausgeführte Code, ob er die Anforderung lokal verarbeiten oder an eine Kopie des Codes weitergeben möchte, die in einer anderen Region ausgeführt wird. Wenn Sie den Modus *Schreiben in eine Region* verwenden, erkennt die Datenverarbeitungsebene möglicherweise, dass es sich nicht um die aktive Region handelt, und erlaubt lokale Lesevorgänge, während alle Schreibvorgänge an eine andere Region weitergeleitet werden. Dieser Code auf Datenverarbeitungsebene muss die Datentopologie und die Regeln für die Weiterleitung kennen und unter Berücksichtigung der aktuellen Einstellungen, die angeben, welche Regionen für welche Daten aktiv sind, zuverlässig durchsetzen. Der äußere Software-Stack innerhalb der Region muss nicht wissen, wie Lese- und Schreibanforderungen von dem Microservice weitergeleitet werden. In einem robusten Design überprüft die empfangende Region, ob sie die aktuelle Primärregion für den Schreibvorgang ist. Ist dies nicht der Fall, wird ein Fehler mit dem Hinweis generiert, dass der globale Zustand korrigiert werden muss. Die empfangende Region könnte den Schreibvorgang auch eine Weile zwischenspeichern, wenn sich die Primärregion gerade ändert. In allen Fällen schreibt der Computing-Stack in einer Region nur auf seinen lokalen DynamoDB-Endpunkt, die Computing-Stacks kommunizieren aber möglicherweise miteinander. ![\[Diagramm der Weiterleitung von Anforderungen auf Datenverarbeitungsebene\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/gt-compute-layer-routing2.png) Die Vanguard Group verwendet für diesen Routing-Prozess ein System namens Global Orchestration and Status Tool (GOaST) und eine Bibliothek namens Global Multi-Region Library (GMRlib), wie auf der [re:Invent 2022](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) vorgestellt. Sie verwenden ein einziges primäres Modell. follow-the-sun GOaST behält den globalen Status bei, ähnlich der ARC-Routing-Steuerung, die im vorherigen Abschnitt beschrieben wurde. Unter Verwendung einer globalen Tabelle verfolgt das Unternehmen, welche Region die Primärregion ist und wann der nächste Wechsel der Primärregion geplant ist. Alle Lese- und Schreiboperationen werden ausgeführt GMRlib, was mit GOa ST koordiniert wird. GMRlib ermöglicht die lokale Ausführung von Lesevorgängen mit geringer Latenz. GMRlib Überprüft bei Schreibvorgängen, ob die lokale Region die aktuelle primäre Region ist. Falls ja, wird der Schreibvorgang direkt abgeschlossen. Wenn nicht, GMRlib leitet die Schreibaufgabe an die GMRlib in der primären Region weiter. Diese empfangende Bibliothek bestätigt, dass sie sich ebenfalls als Primärregion betrachtet, und gibt einen Fehler aus, wenn dies nicht der Fall ist, was auf eine Verzögerung bei der Weitergabe des globalen Zustands hindeutet. Dieses Vorgehen bietet einen Validierungsvorteil, da nicht direkt auf einen DynamoDB-Remote-Endpunkt geschrieben wird. ## Route-53-Weiterleitung von Anforderungen Amazon Application Recovery Controller (ARC) ist eine Domain Name Service (DNS)-Technologie. Bei Route 53 fordert der Client seinen Endpunkt an, indem er nach einem bekannten DNS-Domainnamen sucht, und Route 53 gibt die IP-Adresse des regionalen Endpunkts/der regionalen Endpunkte zurück, den/die es für am geeignetsten hält. Dies wird im folgenden Diagramm veranschaulicht. Route 53 verfügt über eine lange Liste von Weiterleitungsrichtlinien, anhand derer die geeignete Region bestimmt wird. Route 53 kann auch ein Failover-Routing durchführen, um Datenverkehr von Regionen wegzuleiten, die die Zustandsprüfung nicht bestehen. ![\[Diagramm der Weiterleitung von Anforderungen auf Datenverarbeitungsebene\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/gt-rt-53-anycast2_v2.png) Mit dem Modus *Schreiben in eine beliebige Region* oder in Kombination mit der Weiterleitung von Anforderungen auf Datenverarbeitungsebene am Back-End kann Route 53 vollständigen Zugriff erhalten, um die Region auf der Grundlage komplexer interner Regeln zurückzugeben, beispielsweise die Region in nächster Netzwerknähe oder in nächster geografischer Nähe oder eine andere Wahl. Im Modus *Schreiben in eine Region* können Sie Route 53 so konfigurieren, dass es die derzeit aktive Region zurückgibt (mithilfe von Route 53 ARC). Wenn der Client eine Verbindung mit einer passiven Region herstellen möchte (z. B. für Lesevorgänge), kann er nach einem anderen DNS-Namen suchen. **Anmerkung** Die IP-Adressen in der Antwort von Route 53 werden von den Clients für eine gewisse Zeit zwischengespeichert, die in der TTL-Einstellung (Time to Live) für den Domainnamen angegeben ist. Eine längere TTL verlängert das Recovery Time Objective (RTO), damit alle Clients den neuen Endpunkt erkennen. Ein Wert von 60 Sekunden ist typisch für den Failover-Einsatz. Nicht jede Software hält sich perfekt an den Ablauf der DNS-TTL und es kann mehrere Ebenen des DNS-Caching geben, z. B. im Betriebssystem, in der virtuellen Maschine und in der Anwendung. Im Modus *Schreiben in Ihre Region* sollte die Verwendung von Route 53 vermieden werden, es sei denn, Sie verwenden auch die Weiterleitung von Anforderungen auf Datenverarbeitungsebene. ## Weiterleitung von Anforderungen mit Global Accelerator Wie im folgenden Diagramm gezeigt, sucht ein Client mit [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) nach dem bekannten Domainnamen in Route 53. Anstatt jedoch eine IP-Adresse zurückzugewinnen, die einem regionalen Endpunkt entspricht, erhält der Client eine statische Anycast-IP-Adresse, die zum nächstgelegenen AWS Edge-Standort weitergeleitet wird. Ausgehend von diesem Edge-Standort wird der gesamte Datenverkehr über das private AWS -Netzwerk zu einem Endpunkt (z. B. einem Load Balancer oder API Gateway) in einer Region geleitet, die anhand von Weiterleitungsregeln ausgewählt wird, die in Global Accelerator verwaltet werden. Im Vergleich zur Weiterleitung auf der Grundlage von Route-53-Regeln weist die Weiterleitung von Anforderungen mit Global Accelerator geringere Latenzen auf, da der Datenverkehr im öffentlichen Internet reduziert wird. Da Global Accelerator bei der Änderung der Weiterleitungsregeln nicht vom DNS-TTL-Ablauf abhängig ist, kann Global Accelerator die Weiterleitung außerdem schneller anpassen. ![\[Diagramm, das zeigt, wie Schreibvorgänge von Clients mit Global Accelerator funktionieren können.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/gt-routing-gax-excerpt2_v2.png) Im Modus *Schreiben in eine beliebige Region* oder in Kombination mit der Weiterleitung von Anforderungen auf Datenverarbeitungsebene am Back-End funktioniert Global Accelerator problemlos. Der Client stellt eine Verbindung zum nächstgelegenen Edge-Standort her und muss sich keine Gedanken darüber machen, welche Region die Anforderung erhält. Beim *Schreiben in eine Region* müssen die Weiterleitungsregeln von Global Accelerator Anforderungen an die derzeit aktive Region senden. Sie können Zustandsprüfungen verwenden, die künstlich einen Fehler in einer Region melden, die von Ihrem globalen System nicht als aktive Region angesehen wird. Wie bei DNS ist es möglich, einen alternativen DNS-Domainnamen für die Weiterleitung von Leseanforderungen zu verwenden, wenn die Anforderungen aus einer beliebigen Region stammen können. Im Modus *Schreiben in Ihre Region* sollte die Verwendung von Global Accelerator vermieden werden, es sei denn, Sie verwenden auch die Weiterleitung von Anforderungen auf Datenverarbeitungsebene. # Evakuierungsprozesse Beim Evakuieren einer Region werden Aktivitäten, für gewöhnlich Lese- und Schreibaktivitäten oder Leseaktivitäten, aus dieser Region migriert. ## Evakuierung einer Live-Region Möglicherweise entscheiden Sie sich aus einer Reihe von Gründen dafür, eine aktive Region zu evakuieren: als Teil Ihrer üblichen Geschäftsaktivität (z. B. wenn Sie den Modus „In eine follow-the-sun Region schreiben“ verwenden), aufgrund einer Geschäftsentscheidung, die derzeit aktive Region zu ändern, als Reaktion auf Fehler im Software-Stack außerhalb von DynamoDB oder weil Sie auf allgemeine Probleme stoßen, wie z. B. höhere Latenzen als üblich innerhalb der Region. 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 Routing-System an alternative Regionen weiterleiten und die Schreibvorgänge in der evakuierten Region wie gewohnt replizieren lassen. Die Modi „In eine Region schreiben“ und „In Ihre Region schreiben“ werden normalerweise mit MREC-Tabellen verwendet. Daher 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 der neuen aktiven Region beginnen. So stellen Sie sicher, dass künftige Schreibvorgänge mit der neuesten Version der Daten verarbeitet werden. 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, Schreibvorgänge in A anzuhalten, lange genug zu warten, bis diese Vorgänge vollständig an B weitergegeben wurden, den Architektur-Stack zu aktualisieren, um B als aktiv zu erkennen, und dann die Schreibvorgänge 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, Schreibvorgänge 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 geht? Dies ist äußerst unwahrscheinlich, sollte aber dennoch in Betracht gezogen werden. Evakuierung einer Offline-MRSC-Tabelle 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. Evakuierung einer Offline-MREC-Tabelle 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 muss man berücksichtigen, inwieweit die Arbeit mit einem leichten out-of-date Blick auf die Welt weitergehen 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 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)](DynamoDBMapper.OptimisticLocking.md) 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 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. # Planung der Durchsatzkapazität für globale DynamoDB-Tabellen Bei einer Migration des Datenverkehrs von einer Region in eine andere müssen die DynamoDB-Tabelleneinstellungen in Bezug auf die Kapazität sorgfältig geprüft werden. Hier sind einige Überlegungen zur Verwaltung der Schreibkapazität: + Eine globale Tabelle muss sich im On-Demand-Modus befinden oder mit aktiviertem Auto Scaling bereitgestellt werden. + Bei Bereitstellung mit Auto Scaling werden die Schreibeinstellungen (Mindest-, Höchst- und Zielauslastung) regionsübergreifend repliziert. Die Einstellungen für Auto Scaling werden zwar synchronisiert, die tatsächlich bereitgestellte Schreibkapazität kann jedoch unabhängig davon von Region zu Region variieren. + Ein Grund dafür, dass möglicherweise unterschiedliche Schreibkapazitäten bereitgestellt werden, ist die TTL-Funktion. Wenn Sie TTL in DynamoDB aktivieren, können Sie einen Attributnamen angeben, dessen Wert die Ablaufzeit für das Element angibt, und zwar im Unix-Epochenzeitformat in Sekunden. Nach Ablauf dieser Zeit kann DynamoDB das Element löschen, ohne dass Schreibkosten anfallen. Bei globalen Tabellen können Sie TTL in einer beliebigen Region konfigurieren und diese Einstellung wird automatisch auf andere Regionen repliziert, die der globalen Tabelle zugeordnet sind. Wenn ein Element über eine TTL-Regel gelöscht werden kann, kann dies in jeder Region geschehen. Der Löschvorgang wird ausgeführt, ohne dass Schreibeinheiten in der Quelltabelle verbraucht werden. Die Replikattabellen erhalten jedoch einen replizierten Schreibvorgang für diesen Löschvorgang und es fallen Kosten für replizierte Schreibeinheiten an. TTL wird in MRSC-Tabellen nicht unterstützt. + Wenn Sie Auto Scaling verwenden, stellen Sie sicher, dass die Einstellung für die maximale bereitgestellte Schreibkapazität hoch genug ist, um alle Schreibvorgänge sowie alle potenziellen TTL-Löschvorgänge zu bewältigen. Auto Scaling passt jede Region ihrem Verbrauch an Schreibkapazität entsprechend an. Für On-Demand-Tabellen gibt es keine Einstellung für die maximale bereitgestellte Schreibkapazität, das *Schreibdurchsatz-Limit auf Tabellenebene* gibt jedoch an, welche maximale dauerhafte Schreibkapazität die On-Demand-Tabelle zulässt. Das Standardlimit beträgt 40 000, ist jedoch einstellbar. Es wird empfohlen, den Wert hoch genug einzustellen, um alle Schreibvorgänge (einschließlich TTL-Schreibvorgängen) bewältigen zu können, die die On-Demand-Tabelle möglicherweise erfordert. Dieser Wert muss in allen teilnehmenden Regionen gleich sein, wenn Sie globale Tabellen einrichten. Hier sind einige Überlegungen zur Verwaltung der Lesekapazität: + Die Einstellungen für die Verwaltung der Lesekapazität dürfen von Region zu Region unterschiedlich sein, da davon ausgegangen wird, dass verschiedene Regionen möglicherweise unterschiedliche Lesemuster haben. Beim erstmaligen Hinzufügen eines globalen Replikats zu einer Tabelle wird die Kapazität der Quellregion übertragen. Nach der Erstellung können Sie die Einstellungen für die Lesekapazität anpassen und diese Einstellungen werden nicht auf die andere Seite übertragen. + Wenn Sie DynamoDB Auto Scaling verwenden, stellen Sie sicher, dass die Einstellungen für die maximale bereitgestellte Lesekapazität hoch genug sind, um alle Lesevorgänge in allen Regionen bewältigen zu können. Während des Standardbetriebs wird die Lesekapazität möglicherweise auf die Regionen verteilt, doch bei einem Failover sollte die Tabelle automatisch an den höheren Lese-Workload angepasst werden können. Für On-Demand-Tabellen gibt es keine Einstellung für die maximale bereitgestellte Lesekapazität, das *Lesedurchsatz-Limit auf Tabellenebene* gibt jedoch an, welche maximale dauerhafte Lesekapazität die On-Demand-Tabelle zulässt. Das Standardlimit beträgt 40 000, ist jedoch einstellbar. Es wird empfohlen, den Wert hoch genug einzustellen, um alle Lesevorgänge bewältigen zu können, die die Tabelle möglicherweise benötigt, falls alle Lesevorgänge an diese einzelne Region weitergeleitet werden sollten. + Wenn eine Tabelle in einer Region normalerweise keinen Lesedatenverkehr empfängt, nach einem Failover jedoch möglicherweise eine große Menge an Lesedatenverkehr aufnehmen muss, können Sie die Kapazität der Tabelle vorwärmen, damit sie ein höheres Maß an Lesedatenverkehr akzeptieren kann. ARC verfügt über [Bereitschaftsprüfungen](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.rules-resources.html), mit deren Hilfe geprüft werden kann, ob DynamoDB-Regionen ähnliche Tabelleneinstellungen und Kontokontingente aufweisen, unabhängig davon, ob Sie Route 53 zum Weiterleiten von Anforderungen verwenden oder nicht. Diese Bereitschaftsprüfungen können auch bei der Anpassung der Kontingente auf Kontoebene hilfreich sein, um eine Übereinstimmung der Kontingente sicherzustellen. # Checkliste zur Vorbereitung für globale DynamoDB-Tabellen Verwenden Sie die folgende Checkliste für Entscheidungen und Aufgaben bei der Bereitstellung globaler Tabellen. + Ermitteln Sie, ob Ihr Anwendungsfall mehr von einem MRSC- oder einem MREC-Konsistenzmodus profitiert. Benötigen Sie starke Konsistenz, auch wenn die Latenz ist und andere Kompromisse bestehen? + Festlegung, wie viele und welche Regionen an der globalen Tabelle teilnehmen sollen. Wenn Sie MRSC verwenden möchten, entscheiden Sie, ob die dritte Region ein Replikat oder ein Witness sein soll. + Ermittlung des Schreibmodus Ihrer Anwendung. Dies ist nicht dasselbe wie der Konsistenzmodus. Weitere Informationen finden Sie unter [Schreibmodi bei Verwendung von globalen DynamoDB-Tabellen](bp-global-table-design.prescriptive-guidance.writemodes.md). + Planung Ihrer Strategie für [Routing-Strategien in DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) auf der Grundlage Ihres Schreibmodus. + Definieren Sie Ihre [ Evakuierungsprozesse Evakuierung einer Region mit globalen Tabellen Beim Evakuieren einer Region werden Aktivitäten, für gewöhnlich Lese- und Schreibaktivitäten oder Leseaktivitäten, aus dieser Region migriert. Evakuierung einer Live-RegionLive-Regionen Evakuierung einer Live-Region Möglicherweise entscheiden Sie sich aus einer Reihe von Gründen dafür, eine aktive Region zu evakuieren: als Teil Ihrer üblichen Geschäftsaktivität (z. B. wenn Sie den Modus „In eine follow-the-sun Region schreiben“ verwenden), aufgrund einer Geschäftsentscheidung, die derzeit aktive Region zu ändern, als Reaktion auf Fehler im Software-Stack außerhalb von DynamoDB oder weil Sie auf allgemeine Probleme stoßen, wie z. B. höhere Latenzen als üblich innerhalb der Region. 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 Routing-System an alternative Regionen weiterleiten und die Schreibvorgänge in der evakuierten Region wie gewohnt replizieren lassen. Die Modi „In eine Region schreiben“ und „In Ihre Region schreiben“ werden normalerweise mit MREC-Tabellen verwendet. Daher 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 der neuen aktiven Region beginnen. So stellen Sie sicher, dass künftige Schreibvorgänge mit der neuesten Version der Daten verarbeitet werden. 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, Schreibvorgänge in A anzuhalten, lange genug zu warten, bis diese Vorgänge vollständig an B weitergegeben wurden, den Architektur-Stack zu aktualisieren, um B als aktiv zu erkennen, und dann die Schreibvorgänge 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, Schreibvorgänge 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-RegionOffline-Regionen Evakuierung einer Offline-Region Ein Sonderfall ist zu berücksichtigen: Was wäre, wenn Region A ohne vorherige Ankündigung vollständig offline geht? Dies ist äußerst unwahrscheinlich, sollte aber dennoch in Betracht gezogen werden. Evakuierung einer Offline-MRSC-Tabelle 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. Evakuierung einer Offline-MREC-Tabelle 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 muss man berücksichtigen, inwieweit die Arbeit mit einem leichten out-of-date Blick auf die Welt weitergehen 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 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)](DynamoDBMapper.OptimisticLocking.md) 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 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. ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title) [Evakuierungsprozesse](bp-global-table-design.prescriptive-guidance.evacuation.md) basierend auf Ihrem Konsistenzmodus, Ihrem Schreibmodus und Ihrer Routing-Strategie. + Erfassung von Metriken zum Zustand, zur Latenz und zu Fehlern in jeder Region. Eine Liste der DynamoDB-Metriken finden Sie im AWS Blogbeitrag [Monitoring Amazon DynamoDB for Operational Awareness](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/). Dort finden Sie eine Liste der zu beobachtenden Metriken. Sie sollten auch [synthetische Canarys](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (künstliche Anforderungen, um Ausfälle zu erkennen, benannt nach dem Kanarienvogel in Kohlebergwerken) verwenden und eine Live-Beobachtung des Kundendatenverkehrs nutzen. Nicht alle Probleme werden in den DynamoDB-Metriken erkennbar sein. + Wenn Sie MREC verwenden, legen Sie die Alarme für jeden anhaltenden Anstieg bei `ReplicationLatency` ein. Ein Anstieg könnte auf eine versehentliche Fehlkonfiguration hinweisen, bei der die globale Tabelle in verschiedenen Regionen unterschiedliche Schreibeinstellungen aufweist, wodurch es zu fehlgeschlagenen replizierten Anforderungen und höheren Latenzen kommt. Auch auf eine regionale Störung könnte ein solcher Anstieg hindeuten. Ein [gutes Beispiel](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) ist die Generierung einer Warnung, wenn der aktuelle Durchschnitt 180 000 Millisekunden überschreitet. Sie können auch darauf achten, ob der Wert für `ReplicationLatency` auf 0 fällt, was auf eine verzögerte Replikation hindeutet. + Zuweisung ausreichend hoher Einstellungen für die maximale Lese- und Schreibkapazität für jede globale Tabelle. + Ermittlung der Gründe für die Evakuierung einer Region im Voraus. Wenn die Entscheidung menschliches Urteilsvermögen erfordert, sollten alle Überlegungen dokumentiert werden. Diese Arbeit sollte bereits im Voraus sorgfältig und nicht unter Stress durchgeführt werden. + Unterhaltung eines Runbooks für jede Aktion, die bei der Evakuierung einer Region stattfinden muss. Normalerweise ist der Aufwand für die globalen Tabellen sehr gering, doch das Verschieben des restlichen Stacks kann komplex sein. **Anmerkung** Bei Failover-Verfahren hat es sich bewährt, nur auf Operationen auf der Datenebene, nicht auf Operationen auf der Steuerebene zu setzen, da einige Operationen auf Steuerebene bei Regionsausfällen beeinträchtigt sein können. Weitere Informationen finden Sie im AWS Blogbeitrag [Build resilient applications with Amazon DynamoDB global tables: Part 4.](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/) + Regelmäßiger Test aller Aspekte des Runbooks, einschließlich Evakuierungen von Regionen. Ein nicht getestetes Runbook ist ein unzuverlässiges Runbook. + Ziehen Sie die Nutzung von [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) in Betracht, um die Resilienz Ihrer gesamten Anwendung (einschließlich globaler Tabellen) zu bewerten. Das Hub bietet in seinem Dashboard einen umfassenden Überblick über die Widerstandsfähigkeit Ihres gesamten Anwendungsportfolios. + Ziehen Sie die Nutzung von ARC-Bereitschaftsprüfungen in Betracht, um die aktuelle Konfiguration Ihrer Anwendung zu bewerten und Abweichungen von den bewährten Methoden zu verfolgen. + Führen Sie beim Schreiben von Zustandsprüfungen für die Verwendung mit Route 53 oder Global Accelerator eine Reihe von Aufrufen aus, die den vollständigen Datenbankfluss abdecken. Wenn Sie Ihre Überprüfung darauf beschränken, nur zu bestätigen, dass der DynamoDB-Endpunkt aktiv ist, können Sie viele Fehlermodi wie AWS Identity and Access Management (IAM-) Konfigurationsfehler, Probleme bei der Codebereitstellung, Fehler im Stack außerhalb von DynamoDB, überdurchschnittliche Lese- oder Schreiblatenzen usw. nicht abdecken. ## Häufig gestellte Fragen (FAQ) zur Bereitstellung globaler Tabellen **Wie hoch sind die Preise für globale Tabellen?** + Ein Schreibvorgang in einer herkömmlichen DynamoDB-Tabelle wird in Schreibkapazitätseinheiten (WCUsfür bereitgestellte Tabellen) oder Schreibanforderungseinheiten (WRUs) für On-Demand-Tabellen berechnet. Beim Schreiben eines 5-KB-Elements fällt eine Gebühr von 5 Einheiten an. Ein Schreibvorgang in eine globale Tabelle wird in replizierten Schreibkapazitätseinheiten (rWCUs, für bereitgestellte Tabellen) oder replizierten Schreibanforderungseinheiten (rWRUs, für On-Demand-Tabellen) berechnet. r WCUs und r WRUs werden genauso berechnet wie und. WGUs WRUs + rWCU- und rWRU-Gebühren fallen in jeder Region an, in der das Element direkt oder durch Replikation geschrieben wird. Es fallen Gebühren für regionsübergreifende Datenübertragungen an. + Wenn in einen globalen sekundären Index (GSI) geschrieben wird, gilt dies als lokaler Schreibvorgang und es werden reguläre Schreibeinheiten verwendet. + Derzeit ist keine reservierte Kapazität für r WCUs oder r WRUs verfügbar. Der Kauf von reservierter Kapazität für WCUs kann für Tabellen, die Schreibeinheiten GSIs verbrauchen, von Vorteil sein. + Wenn Sie einer globalen Tabelle eine neue Region hinzufügen, bootstrapt DynamoDB die neue Region automatisch und stellt sie Ihnen in Rechnung, als ob es sich um eine Tabellenwiederherstellung handeln würde, basierend auf der GB-Größe der Tabelle. Es fallen auch Gebühren für regionsübergreifende Datenübertragungen an. **Welche Regionen werden von globalen Tabellen unterstützt?** [Global Tables Version 2019.11.21 (aktuell)](GlobalTables.md) unterstützt alle AWS-Regionen für MREC-Tabellen und die folgenden Regionsgruppen für MRSC-Tabellen: + Region-Set USA: USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Oregon) + Region-Set Europa: Europa (Frankfurt), Europa (Irland), Europa (London), Europa (Paris) + Region-Set Asien-Pazifik: Asien-Pazifik (Tokio), Asien-Pazifik (Seoul) und Asien-Pazifik (Osaka). **Wie wird mit globalen Tabellen umgegangen GSIs ?** Wenn Sie in [Version 2019.11.21 (Aktuell)](GlobalTables.md) der globalen Tabellen einen GSI in einer Region erstellen, wird dieser automatisch auch in anderen teilnehmenden Regionen erstellt und automatisch ausgefüllt. **Wie stoppe ich die Replikation einer globalen Tabelle?** + Sie können eine Replikattabelle genauso löschen, wie Sie jede andere Tabelle löschen würden. Wenn Sie die globale Tabelle löschen, wird die Replikation in die betreffende Region beendet und die in dieser Region gespeicherte Tabellenkopie wird gelöscht. Sie können die Replikation jedoch nicht stoppen, solange Sie Kopien der Tabelle als unabhängige Entitäten behalten, und Sie können die Replikation auch nicht unterbrechen. + Eine MRSC-Tabelle muss in genau drei Regionen bereitgestellt werden. Um die Replikate zu löschen, müssen Sie alle Replikate und den Witness löschen, sodass die MRSC-Tabelle zu einer lokalen Tabelle wird. **Wie interagieren DynamoDB-Streams mit globalen Tabellen?** + Jede globale Tabelle erzeugt einen unabhängigen Stream, der auf allen ihren Schreibvorgängen basiert, unabhängig davon, wo diese gestartet wurden. Sie können wählen, ob Sie den DynamoDB-Stream in einer Region oder in allen Regionen (unabhängig voneinander) nutzen möchten. Wenn Sie lokale Schreibvorgänge, aber keine replizierten Schreibvorgänge verarbeiten möchten, können Sie jedem Element Ihr eigenes Regionsattribut hinzufügen, um die schreibende Region zu identifizieren. Sie können dann einen Lambda-Ereignisfilter verwenden, um die Lambda-Funktion nur für Schreibvorgänge in der lokalen Region aufzurufen. Dies ist bei Einfügungen und Aktualisierungen hilfreich, aber nicht bei Löschvorgängen. + Globale Tabellen, die für Multi-Region Eventual Consistency (MREC-Tabellen) konfiguriert sind, replizieren Änderungen, indem sie diese aus einem DynamoDB-Stream in einer Replikattabelle auslesen und auf alle anderen Replikattabellen anwenden. DynamoDB ist daher standardmäßig für alle Replikate in einer globalen MREC-Tabelle aktiviert und kann in diesen Replikaten nicht deaktiviert werden. Der MREC-Replikationsprozess kann mehrere Änderungen in einem kurzen Zeitraum zu einem einzigen replizierten Schreibvorgang kombinieren. Daher kann der Stream jedes Replikats leicht unterschiedliche Datensätze enthalten. DynamoDB-Streams-Datensätze in MREC-Replikaten werden immer elementweise sortiert, wobei die Reihenfolge zwischen den Elementen sich von Replikat zu Replikat unterscheiden kann. + Globale Tabellen, die für Multi-Region Strong Consistency (MRSC-Tabellen) konfiguriert sind, verwenden keine DynamoDB Streams für die Replikation, sodass diese Funktion in MRSC-Replikaten standardmäßig nicht aktiviert ist. DynamoDB Streams können in einem MRSC-Replikat aktiviert werden. DynamoDB-Streams-Datensätze in MRSC-Replikaten sind für jedes Replikat identisch und werden immer elementweise sortiert, wobei die Reihenfolge zwischen den Elementen sich von Replikat zu Replikat unterscheiden kann. **Wie werden Transaktionen in globalen Tabellen gehandhabt?** + Transaktionale Operationen in MRSC-Tabellen führen zu Fehlern. + Transaktionale Operationen in MREC-Tabellen bieten ACID-Garantien (Atomizität, Konsistenz, Isolierung und Zuverlässigkeit) nur in der Region, in der der Schreibvorgang ursprünglich durchgeführt wurde. Regionsübergreifende Transaktionen werden in globalen Tabellen nicht unterstützt. Wenn Sie beispielsweise eine globale MREC-Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) nutzen und eine `TransactWriteItems`-Operation in der Region USA Ost (Ohio) durchführen, sind unter Umständen partiell durchgeführte Transaktionen in der Region USA West (Oregon) zu beobachten, während die Änderungen repliziert werden. Die Änderungen werden erst dann in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden. **Wie interagieren globale Tabellen mit dem DynamoDB-Accelerator-Cache (DAX)?** Globale Tabellen umgehen DAX, indem sie DynamoDB direkt aktualisieren. DAX ist daher nicht bewusst, dass er veraltete Daten enthält. Der DAX-Cache wird erst aktualisiert, wenn die TTL des Caches abläuft. **Werden Tags auf Tabellen weitergegeben?** Nein, Tags werden nicht automatisch weitergegeben. **Sollte ich Tabellen in allen Regionen sichern oder nur in einer?** Die Antwort hängt davon ab, zu welchem Zweck Sie die Sicherung erstellen. + Wenn Sie die Beständigkeit Ihrer Daten sicherstellen möchten, bietet DynamoDB diesen Schutz bereits. Der Service gewährleistet Datenbeständigkeit. + Wenn Sie einen Snapshot für historische Aufzeichnungen aufbewahren möchten (beispielsweise um regulatorische Anforderungen zu erfüllen), sollte eine Sicherung in einer Region ausreichen. Sie können das Backup in weitere Regionen kopieren, indem Sie AWS Backup + Wenn Sie irrtümlich gelöschte oder geänderte Daten wiederherstellen möchten, verwenden Sie [DynamoDB point-in-time Recovery (PITR](PointInTimeRecovery_Howitworks.md)) in einer Region. **Wie stelle ich globale Tabellen bereit mit? CloudFormation** + CloudFormation stellt eine DynamoDB-Tabelle und eine globale Tabelle als zwei separate Ressourcen dar: `AWS::DynamoDB::Table` und. `AWS::DynamoDB::GlobalTable` Ein Ansatz besteht darin, alle Tabellen, die potenziell global sein können, mithilfe des `GlobalTable`-Konstrukts zu erstellen, um sie zunächst als eigenständige Tabellen beizubehalten und später, falls erforderlich, Regionen hinzuzufügen. + CloudFormationIn wird jede globale Tabelle unabhängig von der Anzahl der Replikate von einem einzelnen Stack in einer einzigen Region gesteuert. Wenn Sie Ihre Vorlage bereitstellen, werden alle Replikate als Teil eines einzigen Stack-Vorgangs CloudFormation erstellt und aktualisiert. Sie sollten nicht dieselbe [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html)-Ressource in mehreren Regionen bereitstellen. Dies führt zu Fehlern und wird nicht unterstützt. Wenn Sie Ihre Anwendungsvorlage in mehreren Regionen bereitstellen, können Sie Bedingungen verwenden, um die `AWS::DynamoDB::GlobalTable`-Ressource in einer einzigen Region zu erstellen. Alternativ können Sie Ihre `AWS::DynamoDB::GlobalTable`-Ressourcen in einem von Ihrem Anwendungs-Stack getrennten Stack definieren und sicherstellen, dass er in einer einzigen Region bereitgestellt wird. + Wenn Sie eine reguläre Tabelle haben und diese in eine globale Tabelle konvertieren und gleichzeitig verwalten möchten, legen Sie die Löschrichtlinie auf fest`Retain`, entfernen Sie die Tabelle aus dem Stapel, konvertieren Sie die Tabelle in eine globale Tabelle in der Konsole und importieren Sie dann die globale Tabelle als neue Ressource in den Stack. CloudFormation Weitere Informationen finden Sie im [AWS GitHub Repository](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk). + Die kontoübergreifende Replikation wird zu diesem Zeitpunkt nicht unterstützt. ## Fazit und Ressourcen Globale DynamoDB-Tabellen haben nur sehr wenige Kontrollen, müssen aber dennoch sorgfältig geprüft werden. Sie müssen Ihren Schreibmodus, Ihr Weiterleitungsmodell und Ihre Evakuierungsprozesse festlegen. Sie müssen Ihre Anwendung in jeder Region instrumentieren und bereit sein, Ihre Weiterleitung anzupassen oder eine Evakuierung durchzuführen, um die globale Integrität zu erhalten. Der Vorteil ist, dass Sie auf diese Weise einen global verteilten Datensatz mit Lese- und Schreibvorgängen mit niedriger Latenz erhalten, der auf eine Verfügbarkeit von 99,999 % ausgelegt ist. Weitere Informationen zu globalen DynamoDB-Tabellen finden Sie in den folgenden Ressourcen: + [DynamoDB-Dokumentation](https://docs.aws.amazon.com/dynamodb/) + [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/) + [Bereitschaftsprüfung in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.html) (AWS Dokumentation) + [Route-53-Routing-Richtlinien](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [AWS Globaler Beschleuniger](https://aws.amazon.com/global-accelerator/) + [DynamoDB – Service Level Agreement](https://aws.amazon.com/dynamodb/sla/) + [AWS Grundlagen mehrerer Regionen (Whitepaper](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html))AWS + [Entwurfsmuster für Datenresilienz mit AWS(Präsentation re:Invent](https://www.youtube.com/watch?v=7IA48SOX20c) 2022)AWS + [Wie Fidelity Investments und Reltio mit Amazon DynamoDB modernisiert wurden (AWS Präsentation re:Invent](https://www.youtube.com/watch?v=QUpV5MDu4Ys&t=706s) 2022) + [Entwurfsmuster und bewährte Verfahren für mehrere Regionen](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) (Präsentation re:Invent 2022)AWS + [Disaster Recovery (DR) -Architektur aktiviert AWS, Teil III: Pilot Light und Warm Standby (Blogbeitrag](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/))AWS + [Verwenden Sie Regions-Pinning, um eine Heimatregion für Elemente in einer globalen Amazon DynamoDB-Tabelle festzulegen (Blogbeitrag](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/))AWS + [Überwachung von Amazon DynamoDB im Hinblick auf betriebliches Bewusstsein](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) (AWS Blogbeitrag) + [Skalierung von DynamoDB: Wie sich Partitionen, Hotkeys und Splits für die Wärmeentwicklung auf die Leistung auswirken](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/) (AWS Blogbeitrag) + [Starke regionsübergreifende Konsistenz mit globalen DynamoDB-Tabellen (AWS re:Invent](https://www.youtube.com/watch?v=R-nTs8ZD8mA) 2024-Präsentation)