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.
Kernkonzepte globaler Tabellen
In den folgenden Abschnitten werden die Konzepte und das Verhalten globaler Tabellen in Amazon DynamoDB beschrieben.
Konzepte
Globale Tabellen sind eine DynamoDB-Funktion, die Tabellendaten regionsübergreifend repliziert. AWS
Eine Replikattabelle (oder kurz ein Replikat) ist eine einzelne DynamoDB-Tabelle, die als Teil einer globalen Tabelle fungiert. Eine globale Tabelle besteht aus zwei oder mehr Replikattabellen in verschiedenen Regionen. AWS Jede globale Tabelle kann nur über eine Replikattabelle je AWS -Region verfügen. Alle Replikate in einer globalen Tabelle verwenden denselben Tabellennamen, dasselbe Primärschlüsselschema und dieselben Elementdaten.
Wenn eine Anwendung Daten in eine Replikattabelle in einer Region schreibt, verteilt DynamoDB den Schreibvorgang automatisch auf die anderen Replikattabellen in der globalen Tabelle. Weitere Informationen zu den ersten Schritten mit globalen Tabellen finden Sie unter Tutorials: Erstellen von globalen Tabellen oderTutorials: Globale Tabellen mit mehreren Konten erstellen.
Versionen
Es gibt zwei Versionen von globalen DynamoDB-Tabellen: Version 2019.11.21 (Aktuell) und Version 2017.11.29 (Legacy) der globalen Tabellen. Sie sollten nach Möglichkeit Global Tables Version 2019.11.21 (Aktuell) verwenden. Die Informationen in diesem Abschnitt der Dokumentation gelten für die Version 2019.11.21 (Aktuell). Weitere Informationen finden Sie unter Ermitteln der Version einer globalen Tabelle. Ermitteln der Version einer globalen Tabelle
Verfügbarkeit
Globale Tabellen tragen zur Verbesserung der Geschäftskontinuität bei, da sie die Implementierung einer hoch verfügbaren Architektur für mehrere Regionen erleichtern. Wenn eine Arbeitslast in einer einzelnen AWS Region beeinträchtigt wird, können Sie den Anwendungsdatenverkehr in eine andere Region verlagern und Lese- und Schreibvorgänge in einer anderen Replikattabelle in derselben globalen Tabelle durchführen.
Jede Replikattabelle in einer globalen Tabelle bietet dieselbe Stabilität und Verfügbarkeit wie eine DynamoDB-Tabelle mit einer Region. Globale Tabellen bieten ein Service Level Agreement (SLA)
Testen mit Fehlerinjektionen
Sowohl die globalen MREC- als auch die MRSC-Tabellen sind in den AWSAWS Fault Injection Service (FIS) integriert, einen vollständig verwalteten Dienst zur Durchführung kontrollierter Fehlerinjektionsexperimente zur Verbesserung der Ausfallsicherheit einer Anwendung. Mit AWS FIS können Sie:
-
Erstellen Sie Versuchsvorlagen, die spezifische Fehlerszenarien definieren.
-
Injizieren Sie Fehler, um die Ausfallsicherheit von Anwendungen zu überprüfen, indem Sie die Regionsisolierung simulieren (d. h. die Replikation zu und von einem ausgewählten Replikat unterbrechen), um die Fehlerbehandlung, Wiederherstellungsmechanismen und das Verhalten bei Störungen in einer Region zu testen. AWS
In einer globalen Tabelle mit Replikaten in USA Ost (Nord-Virginia), USA Ost (Ohio) und USA West (Oregon) können Sie beispielsweise ein Experiment in USA Ost (Ohio) durchführen, um die dortige Regionsisolierung zu testen, während USA Ost (Nord-Virginia) und USA West (Oregon) ihren normalen Betrieb fortsetzen. Diese kontrollierten Tests helfen Ihnen dabei, potenzielle Probleme zu identifizieren und zu lösen, bevor sie sich auf den Produktions-Workload auswirken.
Eine vollständige Liste der von AWS FIS unterstützten Aktionen und regionsübergreifender Konnektivität zum Anhalten der DynamoDB-Replikation zwischen Regionen finden Sie unter Aktionsziele im AWS FIS-Benutzerhandbuch.
Informationen zu globalen Tabellenaktionen von Amazon DynamoDB, die in AWS FIS verfügbar sind, finden Sie unter DynamoDB Global Tables Actions Reference im FIS-Benutzerhandbuch.AWS
Informationen zu den ersten Schritten mit der Durchführung von Fault-Injection-Experimenten finden Sie unter Planung Ihrer AWS FIS-Experimente im FIS-Benutzerhandbuch. AWS
Anmerkung
Bei AWS FIS Experimenten in MRSC sind eventuell konsistente Lesevorgänge zulässig, Aktualisierungen der Tabelleneinstellungen — wie z. B. das Ändern des Abrechnungsmodus oder die Konfiguration des Tabellendurchsatzes — sind jedoch nicht zulässig, ähnlich wie bei MREC. Weitere Informationen FaultInjectionServiceInducedErrorszum Fehlercode finden Sie in der CloudWatch Metrik.
Time to Live (TTL)
In globalen Tabellen mit MREC-Konfiguration kann die Konfiguration von Time To Live (TTL) gelöscht werden. Die TTL-Einstellungen werden automatisch für alle Replikate einer globalen Tabelle synchronisiert. Wenn TTL ein Element aus einem Replikat in einer Region löscht, wird der Löschvorgang auf alle anderen Replikate in der globalen Tabelle repliziert. TTL verbraucht keine Schreibkapazität; das Löschen von TTL wird Ihnen in der Region, in der der Löschvorgang stattgefunden hat, nicht in Rechnung gestellt. In allen anderen Regionen, deren globale Tabelle ein Replikat enthält, wird Ihnen jedoch der replizierte Löschvorgang in Rechnung gestellt.
Die Replikation eines TTL-Löschvorgangs verbraucht Schreibkapazität in den Replikaten, in die der Löschvorgang repliziert wird. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Schreibdurchsatz und TTL-Löschdurchsatz die bereitgestellte Schreibkapazität überschreitet.
Globale Tabellen mit MRSC-Konfiguration unterstützen die Konfiguration des TTL-Löschvorgangs nicht.
Streams
Globale Tabellen mit MREC-Konfiguration replizieren Änderungen, indem sie diese aus einem DynamoDB-Stream in einer Replikattabelle auslesen und auf alle anderen Replikattabellen anwenden. Streams sind daher standardmäßig für alle Replikate in einer globalen MREC-Tabelle aktiviert und können in diesen Replikaten nicht deaktiviert werden. Der MREC-Replikationsprozess kann mehrere Änderungen in einem kurzen Zeitraum zu einem einzigen replizierten Schreibvorgang kombinieren, was dazu führt, dass der Stream jedes Replikats Datensätze enthält, die sich geringfügig unterscheiden. Streams-Datensätze auf MREC-Replikaten behalten die Reihenfolge für alle Änderungen am selben Objekt bei, aber die relative Reihenfolge der Änderungen an verschiedenen Elementen kann je nach Replikat variieren.
Wenn Sie eine Anwendung schreiben möchten, die Streams-Datensätze für Änderungen verarbeitet, die in einer bestimmten Region, aber nicht in anderen Regionen in einer globalen Tabelle vorgenommen wurden, können Sie jedem Element ein Attribut hinzufügen, das definiert, in welcher Region die Änderung für dieses Element stattgefunden hat. Sie können dieses Attribut verwenden, um Streams-Datensätze nach Änderungen zu filtern, die in anderen Regionen aufgetreten sind und hierzu auch Lambda-Ereignisfilter verwenden, um Lambda-Funktionen nur für Änderungen in einer bestimmten Region aufzurufen.
Globale Tabellen mit MRSC-Konfiguration verwenden keine DynamoDB Streams für die Replikation, sodass Streams in MRSC-Replikaten standardmäßig nicht aktiviert sind. Streams können in einem MRSC-Replikat aktiviert werden. Streams-Datensätze in MRSC-Replikaten sind für jedes Replikat identisch, auch in Bezug auf ihre Reihenfolge.
Transaktionen
In einer globalen Tabelle mit MREC-Konfiguration sind DynamoDB-Transaktionsoperationen (TransactWriteItems und TransactGetItems) nur innerhalb der Region, in der der Vorgang aufgerufen wurde, unteilbar. Schreibtransaktionen werden nicht als Einheit regionsübergreifend repliziert, was bedeutet, dass nur einige Schreibvorgänge in einer Transaktion zu einem bestimmten Zeitpunkt durch Lesevorgänge in anderen Replikaten zurückgegeben werden können.
Wenn Sie beispielsweise eine globale 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 in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden.
Globale Tabellen mit MRSC-Konfiguration unterstützen keine Transaktionsvorgänge und geben einen Fehler zurück, wenn solche Operationen in einem MRSC-Replikat aufgerufen werden.
Lese- und Schreibdurchsatz
Modus bereitgestellter Kapazität
Eine Replikation verbraucht Schreibkapazität. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Anwendungsschreibdurchsatz und Replikationsschreibdurchsatz die bereitgestellte Schreibkapazität überschreitet. Bei globalen Tabellen, die den Bereitstellungsmodus verwenden, werden die Auto Scaling-Einstellungen für Lese- und Schreibkapazitäten zwischen den Replikaten synchronisiert.
Sie können die Lesekapazitätseinstellungen für jedes Replikat in einer globalen Tabelle unabhängig konfigurieren, indem Sie den ProvisionedThroughputOverrideParameter auf Replikatebene verwenden. Standardmäßig werden Änderungen an der bereitgestellten Lesekapazität auf alle Replikate in der globalen Tabelle angewendet. Beim Hinzufügen eines neuen Replikats zu einer globalen Tabelle wird die Lesekapazität der Quelltabelle oder des Replikats als Anfangswert verwendet, sofern nicht ausdrücklich eine Überschreibung auf Replikatebene angegeben ist.
On-Demand-Modus
Bei globalen Tabellen, die für den On-Demand-Modus konfiguriert sind, wird die Schreibkapazität automatisch über alle Replikate hinweg synchronisiert. DynamoDB passt die Kapazität automatisch an den Datenverkehr an, und es müssen keine replikatspezifischen Lese- oder Schreibkapazitätseinstellungen verwaltet werden.
Überwachen globaler Tabellen
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.
Globale Tabellen mit MRSC-Konfiguration veröffentlichen keine ReplicationLatency-Metrik.
Überlegungen zur Verwaltung globaler Tabellen
Sie können eine Tabelle, die zum Hinzufügen des neuen Replikats einer globalen Tabelle verwendet wurde, erst 24 Stunden nach der Erstellung des neuen Replikats löschen.
Wenn Sie eine AWS Region deaktivieren, die globale Tabellenreplikate enthält, werden diese Replikate 20 Stunden nach der Deaktivierung der Region dauerhaft in Tabellen mit nur einer Region konvertiert.
