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.
Mithilfe globaler Amazon DynamoDB-Tabellen können Sie Ihre Tabellendaten regionsübergreifend replizieren. AWS Es ist wichtig, dass die Replikattabellen und sekundären Indexen in Ihrer globalen Tabelle über identische Schreibkapazitätseinstellungen verfügen, um eine ordnungsgemäße Replikation der Daten sicherzustellen.
Aus Gründen künftiger Klarheit kann es nützlich sein, die Region nicht in den Namen einer Tabelle aufzunehmen, da diese später in eine globale Tabelle umgewandelt werden könnte.
Warnung
Der Tabellenname für jede globale Tabelle muss innerhalb Ihres Kontos eindeutig sein. AWS
Version der globalen Tabellen
Informationen zum Ermitteln der Version der globalen Tabelle, die Sie verwenden, finden Sie unterErmitteln der Version der DynamoDB-Tabelle, die Sie verwenden.
Anforderungen zum Verwalten der Kapazität
Für eine globale Tabelle muss die Durchsatzkapazität auf eine von zwei Arten konfiguriert sein:
-
Kapazitätsmodus auf Abruf, gemessen in replizierten Schreibanforderungseinheiten (rWRUs)
-
Bereitgestellter Kapazitätsmodus mit auto Skalierung, gemessen in replizierten Schreibkapazitätseinheiten (r) WCUs
Durch die Verwendung des bereitgestellten Kapazitätsmodus mit Auto Scaling oder Bedarfskapazität-Modus wird sichergestellt, dass eine globale Tabelle immer über ausreichende Kapazität verfügt, um replizierte Schreibvorgänge in alle Regionen der globalen Tabelle auszuführen.
Anmerkung
Beim Umschalten von einem Tabellenkapazitätsmodus in den anderen Kapazitätsmodus in einer beliebigen Region wird der Modus für alle Replikate umgeschaltet.
Bereitstellen globaler Tabellen
In AWS CloudFormation wird jede globale Tabelle von einem einzelnen Stack in einer einzigen Region gesteuert. Dies ist unabhängig von der Anzahl der Replikate. Wenn Sie Ihre Vorlage bereitstellen, CloudFormation erstellt/aktualisiert alle Replikate als Teil eines einzelnen Stack-Vorgangs. Daher sollten Sie nicht dieselbe AWS::DynamoDB::GlobalTable-Ressource in mehreren Regionen bereitstellen. Dies wird nicht unterstützt und führt zu Fehlern.
Wenn Sie Ihre Anwendungsvorlage in mehreren Regionen bereitstellen, können Sie Bedingungen verwenden, um die Ressource nur in einer Region zu erstellen. Alternativ können Sie Ihre AWS::DynamoDB::GlobalTable-Ressourcen in einem Stack getrennt von Ihrem Anwendungs-Stack auswählen und sicherstellen, dass er nur in einer einzigen Region bereitgestellt wird. Weitere Informationen finden Sie unter Globale Tabellen in CloudFormation
Auf eine DynamoDB-Tabelle wird durch AWS::DynamoDB::Table und auf eine globale Tabelle durch AWS::DynamoDB::GlobalTable verwiesen. Was CloudFormation das betrifft, so sind sie damit im Wesentlichen zwei verschiedene Ressourcen. Daher besteht ein Ansatz darin, alle Tabellen, die jemals global werden könnten, mithilfe des GlobalTable-Konstrukts zu erstellen. Sie können sie dann zunächst als eigenständige Tabellen beibehalten und sie später bei Bedarf zu Regionen hinzufügen.
Wenn Sie eine normale Tabelle haben und diese während der Verwendung konvertieren möchten CloudFormation, empfiehlt sich die folgende Methode:
Legen Sie die Löschrichtlinie fest, die beibehalten werden soll.
Entfernen Sie die Tabelle aus dem Stack.
Konvertieren Sie die Tabelle in der Konsole in eine globale Tabelle.
Importieren Sie die globale Tabelle als neue Ressource in den Stack.
Anmerkung
Die kontoübergreifende Replikation wird zu diesem Zeitpunkt nicht unterstützt.
Verwendung globaler Tabellen zur Bewältigung eines potenziellen Ausfalls einer Region
Sie müssen unabhängige Kopien Ihres Ausführungs-Stacks in alternativen Regionen gespeichert haben oder schnell erstellen können, wobei jede Region auf ihren lokalen DynamoDB-Endpunkt zugreift.
Verwenden Sie Route53 oder AWS Global Accelerator um eine Route zur nächstgelegenen gesunden Region zu erstellen. Weisen Sie den Client alternativ darauf hin, dass er mehrere Endpunkte verwenden kann.
Führen Sie in jeder Region Zustandsprüfungen durch, um zuverlässig festzustellen, ob ein Problem mit dem Stack vorliegt und DynamoDB beispielsweise beeinträchtigt ist. Pingen Sie beispielsweise den DynamoDB-Endpunkt nicht einfach, um festzustellen, ob er aktiv ist. Führen Sie tatsächlich einen Aufruf durch, der einen vollständigen erfolgreichen Datenbankfluss sicherstellt.
Schlägt die Zustandsprüfung fehl, kann der Datenverkehr in andere Regionen weitergeleitet werden (indem der DNS-Eintrag mit Route53 aktualisiert wird, Global Accelerator anders weiterleitet oder der Client einen anderen Endpunkt auswählt). Globale Tabellen haben ein gutes RPO (Recovery Point Objective), da die Daten kontinuierlich synchronisiert werden, und ein gutes RTO (Recovery Time Objective), da beide Regionen eine Tabelle immer sowohl für den Lese- als auch für den Schreibverkehr bereit halten.
Weitere Informationen zu Zustandsprüfungen finden Sie unter Typen von Zustandsprüfungen.
Anmerkung
DynamoDB ist ein Kernservice, auf dem andere Services häufig ihren Betrieb auf der Steuerebene aufbauen. Daher ist es unwahrscheinlich, dass Sie auf ein Szenario stoßen, in dem DynamoDB in einer Region einen eingeschränkten Service hat, während andere Services davon nicht betroffen sind.
Sichern globaler Tabellen
Beim Sichern globaler Tabellen sollte ein Backup von Tabellen in einer Region ausreichend sein. Ein Backup aller Tabellen in allen Regionen sollte nicht erforderlich sein. Wenn der Zweck darin besteht, irrtümlich gelöschte oder geänderte Daten wiederherstellen zu können, sollte PITR in einer Region ausreichen. Entsprechend sollte ein Backup in einer Region ausreichen, wenn ein Snapshot für historische Zwecke wie regulatorische Anforderungen aufbewahrt wird. Die gesicherten Daten können über AWS Backup in mehrere Regionen repliziert werden.
Replikate und Berechnung von Schreibeinheiten
Für die Planung sollten Sie die Anzahl der Schreibvorgänge, die eine Region ausführen soll, zur Anzahl der Schreibvorgänge für jede andere Region hinzufügen. Dies ist wichtig, da jeder Schreibvorgang, der in einer Region ausgeführt wird, auch in jeder Replikatregion durchgeführt werden muss. Wenn Sie nicht über genügend Kapazität verfügen, um alle Schreibvorgänge zu verarbeiten, treten Kapazitätsausnahmen auf. Darüber hinaus werden die Wartezeiten für die interregionale Replikation steigen.
Angenommen, Sie erwarten 5 Schreibvorgänge pro Sekunde in die Replikattabelle in Ohio, 10 Schreibvorgänge pro Sekunde in die Replikattabelle in Nord-Virginia und 5 Schreibvorgänge pro Sekunde in die Replikattabelle in Irland. In diesem Fall sollten Sie damit rechnen, WRUs in jeder Region 20 r WCUs oder r zu konsumieren: Ohio, Nord-Virginia und Irland. Mit anderen Worten, Sie sollten damit rechnen, in allen drei Regionen WCUs insgesamt 60 r zu konsumieren.
Einzelheiten zur bereitgestellten Kapazität mit Auto Scaling und DynamoDB finden Sie unter Automatische Verwaltung der Durchsatzkapazität mit DynamoDB-Auto-Scaling.
Anmerkung
Wenn eine Tabelle im bereitgestellten Kapazitätsmodus mit Auto Scaling ausgeführt wird, darf die bereitgestellte Schreibkapazität innerhalb dieser Auto-Scaling-Einstellungen jeder Region angepasst werden.
