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.

Bewährte Methoden und Anforderungen für die Verwaltung globaler DynamoDB-Tabellen

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.

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:

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.

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:

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.

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.