So funktionieren globale DynamoDB-Tabellen - Amazon DynamoDB
Überwachen

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.

So funktionieren globale DynamoDB-Tabellen

Globale Tabellen mit mehreren Konten erweitern die vollständig verwalteten, serverlosen, regionsübergreifenden und multiaktiven Funktionen von DynamoDB auf mehrere Konten. AWS Globale Tabellen mit mehreren Konten replizieren Daten über AWS Regionen und Konten hinweg und bieten dabei dieselbe aktive und aktive Funktionalität wie globale Tabellen mit demselben Konto. Wenn Sie in ein Replikat schreiben, repliziert DynamoDB die Daten auf alle anderen Replikate.

Zu den wichtigsten Unterschieden zu globalen Tabellen mit demselben Konto gehören:

  • Die Replikation mehrerer Konten wird für globale Tabellen mit Multi-Region Eventual Consistency (MREC) unterstützt.

  • Sie können Replikate nur hinzufügen, indem Sie mit einer Tabelle mit einer einzigen Region beginnen. Die Konvertierung einer vorhandenen globalen Tabelle mit demselben Konto in eine Konfiguration mit mehreren Konten wird nicht unterstützt. Um zu migrieren, müssen Sie vorhandene Replikate löschen, um zu einer Tabelle mit nur einer Region zurückzukehren, bevor Sie eine neue globale Tabelle mit mehreren Konten erstellen.

  • Jedes Replikat muss sich in einem separaten Konto befinden. AWS Für eine globale Tabelle mit mehreren Konten und N Replikaten benötigen Sie N Konten.

  • Globale Tabellen mit mehreren Konten verwenden standardmäßig einheitliche Tabelleneinstellungen für alle Replikate. Alle Replikate verwenden automatisch dieselbe Konfiguration (wie Durchsatzmodus, TTL und PITR), und im Gegensatz zu globalen Tabellen mit demselben Konto können diese Einstellungen nicht pro Replikat außer Kraft gesetzt werden.

  • Kunden müssen in ihren Ressourcenrichtlinien Replikationsberechtigungen für den DynamoDB-Dienstprinzipal für globale Tabellen bereitstellen.

Globale Tabellen mit mehreren Konten verwenden dieselbe zugrunde liegende Replikationstechnologie wie globale Tabellen mit demselben Konto. Tabelleneinstellungen werden automatisch auf alle regionalen Replikate repliziert, und Kunden können die Einstellungen nicht für jedes Replikat überschreiben oder anpassen. Dies gewährleistet eine konsistente Konfiguration und ein vorhersehbares Verhalten für mehrere AWS Konten, die an derselben globalen Tabelle teilnehmen.

Einstellungen in globalen DynamoDB-Tabellen definieren, wie sich eine Tabelle verhält und wie Daten regionsübergreifend repliziert werden. Diese Einstellungen werden während der Tabellenerstellung oder APIs beim Hinzufügen eines neuen regionalen Replikats über die DynamoDB-Steuerebene konfiguriert.

Bei der Erstellung einer globalen Tabelle mit mehreren Konten müssen Kunden GlobalTableSettingsReplicationMode = ENABLED für jedes regionale Replikat Einstellungen vornehmen. Dadurch wird sichergestellt, dass in einer Region vorgenommene Konfigurationsänderungen automatisch auf alle anderen Regionen übertragen werden, die Teil der globalen Tabelle sind.

Sie können die Replikation der Einstellungen nach der Tabellenerstellung aktivieren. Dies unterstützt das Szenario, in dem eine Tabelle ursprünglich als regionale Tabelle erstellt und später zu einer globalen Tabelle mit mehreren Konten aktualisiert wurde.

Synchronisierte Einstellungen

Die folgenden Tabelleneinstellungen werden immer für alle Replikate in einer globalen Tabelle mit mehreren Konten synchronisiert:

Anmerkung

Im Gegensatz zu globalen Tabellen mit demselben Konto lassen globale Tabellen mit mehreren Konten keine regionsspezifischen Überschreibungen für diese Einstellungen zu. Die einzige Ausnahme besteht darin, dass Überschreibungen für Richtlinien zur auto-scaling von Lesevorgängen (Tabellen und GSIs) zulässig sind, da es sich um separate externe Ressourcen handelt.

  • Kapazitätsmodus (bereitgestellte oder On-Demand-Kapazität)

  • Von der Tabelle bereitgestellte Lese- und Schreibkapazität

  • auto Skalierung beim Lesen und Schreiben von Tabellen

  • Definition des lokalen sekundären Index (LSI)

  • Definition des globalen sekundären Index (GSI)

  • Von GSI bereitgestellte Lese- und Schreibkapazität

  • GSI Auto Scaling mit Lese- und Schreibzugriff

  • Streams-Definition im MREC-Modus

  • Time to Live (TTL)

  • Warmdurchsatz

  • Maximaler Lese- und Schreibdurchsatz auf Abruf

Nicht synchronisierte Einstellungen

Die folgenden Einstellungen werden nicht zwischen Replikaten synchronisiert und müssen für jede Replikattabelle in jeder Region unabhängig konfiguriert werden.

  • Tabellenklasse

  • Typ der serverseitigen Verschlüsselung (Server-Side Encryption, SSE)

  • KMS-Schlüssel-ID für serverseitige Verschlüsselung (SSE)

  • Löschschutz

  • Kinesis Data Streams (KDSD)

  • Tags (Markierungen)

  • Ressourcenrichtlinie

  • Tabelle Cloudwatch-Contributor Insights (CCI)

  • Einblicke in GSI Cloudwatch—Contributor (CCI)

Überwachen

In globalen Tabellen, die für Multi-Region Eventual Consistency (MREC) konfiguriert sind, wird die Metrik veröffentlicht. ReplicationLatency CloudWatch Diese Metrik misst die verstrichene Zeit zwischen dem Schreiben eines Elements in eine Replikattabelle und dem Erscheinen dieses Elements in einem anderen Replikat in der globalen Tabelle. ReplicationLatency wird in Millisekunden ausgedrückt und für jedes Paar aus Quell- und Zielregion ausgegeben.

Typische ReplicationLatency Werte hängen von der Entfernung zwischen den ausgewählten AWS Regionen sowie von anderen Variablen wie Workload-Typ und Durchsatz ab. Beispiel: Ein Quellreplikat in der Region USA West (Nordkalifornien) (us-west-1) weist im Vergleich zur Region Afrika (Kapstadt) (af-south-1) einen niedrigeren Wert für ReplicationLatency auf als die Region USA West (Oregon) (us-west-2).

Ein erhöhter Wert für ReplicationLatency könnte darauf hinweisen, dass Updates von einem Replikat nicht in einem angemessenen Zeitraum an andere Replikattabellen verteilt werden. In diesem Fall können Sie die Lese- und Schreibaktivität Ihrer Anwendung vorübergehend in eine andere AWS Region umleiten.

Behandlung von Problemen mit der Replikationslatenz in globalen Tabellen mit mehreren Konten

Wenn aufgrund von vom Kunden verursachten Problemen mit einer Replikattabelle ReplicationLatency mehr als 3 Stunden vergangen sind, sendet DynamoDB eine Benachrichtigung, in der der Kunde aufgefordert wird, das zugrunde liegende Problem zu beheben. Zu den häufigsten kundenbedingten Problemen, die eine Replikation verhindern können, gehören:

  • Entfernen der erforderlichen Berechtigungen aus der Ressourcenrichtlinie der Replikattabelle

  • Abmeldung von einer AWS Region, in der ein Replikat der globalen Tabelle mit mehreren Konten gehostet wird

  • Verweigerung der für die Entschlüsselung von Daten erforderlichen AWS KMS-Schlüsselberechtigungen für die Tabelle

DynamoDB sendet innerhalb von 3 Stunden bei erhöhter Replikationslatenz eine erste Benachrichtigung, gefolgt von einer zweiten Benachrichtigung nach 20 Stunden, falls das Problem weiterhin besteht. Wenn das Problem nicht innerhalb des erforderlichen Zeitfensters behoben wird, trennt DynamoDB das Replikat automatisch von der globalen Tabelle. Das betroffene Replikat wird dann in eine regionale Tabelle konvertiert.