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
Multi-account Globale Tabellen erweitern die vollständig verwalteten, serverlosen, regionsübergreifenden und multiaktiven Funktionen von DynamoDB-Tabellen auf mehrere Konten. AWS Multi-account Globale Tabellen replizieren Daten über AWS Regionen und Konten hinweg und bieten dieselbe Aktiv-Aktiv-Funktionalität wie globale Tabellen für dieselben Konten. Wenn Sie in ein Replikat schreiben, repliziert DynamoDB die Daten auf alle anderen Replikate.
Zu den wichtigsten Unterschieden zu globalen Tabellen mit gleichen Konten gehören:
-
Multi-account Die Replikation wird für globale MREC-Tabellen (Multiregion Eventual Consistency) unterstützt.
-
Sie können Replikate nur hinzufügen, indem Sie mit einer Tabelle mit einer einzelnen Region beginnen. Die Konvertierung einer vorhandenen globalen Tabelle mit demselben Konto in eine Konfiguration mit mehreren Konten wird nicht unterstützt. Für die Migration müssen Sie vorhandene Replikate löschen, um zu einer Single-Region-Tabelle 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 müssen Sie über N Konten verfügen.
-
Multi-account Globale Tabellen verwenden standardmäßig einheitliche Tabelleneinstellungen für alle Replikate. Alle Replikate verwenden automatisch dieselbe Konfiguration (z. B. Durchsatzmodus und TTL), und im Gegensatz zu globalen Tabellen mit gleichen Konten können diese Einstellungen nicht pro Replikat überschrieben werden.
-
Kunden müssen in ihren Ressourcenrichtlinien Replikationsberechtigungen für den DynamoDB-Service Principal für globale Tabellen gewähren.
Multi-account Globale Tabellen verwenden dieselbe zugrundeliegende Replikationstechnologie wie globale Tabellen mit gleichen Konten. Tabelleneinstellungen werden automatisch auf alle regionalen Replikate repliziert, und Kunden können die Einstellungen pro Replikat nicht ü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 über DynamoDB-Steuerungsebenen-APIs während der Tabellenerstellung oder beim Hinzufügen eines neuen regionalen Replikats konfiguriert.
Bei der Erstellung einer globalen Tabelle mit mehreren Konten müssen Kunden diese Einstellungen GlobalTableSettingsReplicationMode = ENABLED für jedes regionale Replikat vornehmen. Dadurch wird sichergestellt, dass in einer Region vorgenommene Konfigurationsänderungen automatisch auf alle anderen Regionen übertragen werden, die an der globalen Tabelle teilnehmen.
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 wird.
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 gleichen Konten lassen globale Tabellen mit mehreren Konten für diese Einstellungen keine regionsspezifischen Überschreibungen zu. Die einzige Ausnahme ist, dass Überschreibungen für Richtlinien zur automatischen Leseskalierung (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
-
Automatische Skalierung von Lese- und Schreibvorgängen für 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 für Lese- und Schreibvorgänge
-
Streams-Definition im MREC-Modus
-
Time to Live (TTL)
-
Warmdurchsatz
-
On-demand maximaler Lese- und Schreibdurchsatz
Non-Synchronized Einstellungen
Die folgenden Einstellungen werden nicht zwischen Replikaten synchronisiert und müssen für jede Replikattabelle in jeder Region unabhängig konfiguriert werden.
-
Tabellenklasse
-
Server-side Verschlüsselungstyp (SSE)
-
Point-in-time Wiederherstellung
-
Server-side KMS-Schlüssel-ID für Verschlüsselung (SSE)
-
Löschschutz
-
Kinesis-Datenströme (KDSD)
-
Tags (Markierungen)
-
Ressourcenrichtlinie
-
Tabelle Cloudwatch-Contributor Insights (CCI)
-
GSI Cloudwatch-Contributor Insights (CCI)
Überwachen
Globale Tabellen, die für Multiregion Eventual Consistency (MREC) konfiguriert sind, veröffentlichen die Metrik in. 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äten Ihrer Anwendung vorübergehend in eine andere AWS Region umleiten.
Behandlung von Problemen mit der Replikationslatenz in Multi-account globalen Tabellen
Wenn aufgrund kundenbedingter Probleme mit einer Replikattabelle ReplicationLatency mehr als 3 Stunden überschritten werden, 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, die ein Replikat der globalen Tabelle mit mehreren Konten hostet
-
Verweigern der AWS KMS-Schlüsselberechtigungen der Tabelle, die zum Entschlüsseln von Daten erforderlich sind
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.
