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. # 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.