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.
Vorbereitungscheckliste für globale DynamoDB-Tabellen und häufig gestellte Fragen
Verwenden Sie die folgende Checkliste für Entscheidungen und Aufgaben bei der Bereitstellung globaler Tabellen.
Festlegung, wie viele und welche Regionen an der globalen Tabelle teilnehmen sollen.
Ermittlung des Schreibmodus Ihrer Anwendung. Weitere Informationen finden Sie unter Schreibmodi mit globalen DynamoDB-Tabellen.
Planung Ihrer Strategie für Anforderungsweiterleitung mit globalen DynamoDB-Tabellen auf der Grundlage Ihres Schreibmodus.
Definieren Sie Ihren Evakuierungsplan auf der Grundlage Ihres Schreibmodus und Ihrer Routing-Strategie.
Erfassung von Metriken zum Zustand, zur Latenz und zu Fehlern in jeder Region. Eine Liste der DynamoDB-Metriken finden Sie im AWS Blogbeitrag Monitoring Amazon DynamoDB for Operational Awareness
. Dort finden Sie eine Liste der zu beobachtenden Metriken. Sie sollten auch synthetische Canarys (künstliche Anforderungen, um Ausfälle zu erkennen, benannt nach dem Kanarienvogel in Kohlebergwerken) verwenden und eine Live-Beobachtung des Kundendatenverkehrs nutzen. Nicht alle Probleme werden in den DynamoDB-Metriken erkennbar sein. Einstellen von Alarmen für jeden anhaltenden Anstieg der
ReplicationLatency. Ein Anstieg könnte auf eine versehentliche Fehlkonfiguration hinweisen, bei der die globale Tabelle in verschiedenen Regionen unterschiedliche Schreibeinstellungen aufweist, wodurch es zu fehlgeschlagenen replizierten Anforderungen und höheren Latenzen kommt. Auch auf eine regionale Störung könnte ein solcher Anstieg hindeuten. Ein gutes Beispielist die Generierung einer Warnung, wenn der aktuelle Durchschnitt 180 000 Millisekunden überschreitet. Sie können auch darauf achten, dass der Wert auf 0 ReplicationLatencyfällt, was auf eine blockierte Replikation hindeutet.Zuweisung ausreichend hoher Einstellungen für die maximale Lese- und Schreibkapazität für jede globale Tabelle.
Ermittlung der Gründe für die Evakuierung einer Region im Voraus. Wenn die Entscheidung menschliches Urteilsvermögen erfordert, sollten alle Überlegungen dokumentiert werden. Diese Arbeit sollte bereits im Voraus sorgfältig und nicht unter Stress durchgeführt werden.
Unterhaltung eines Runbooks für jede Aktion, die bei der Evakuierung einer Region stattfinden muss. Normalerweise ist der Aufwand für die globalen Tabellen sehr gering, doch das Verschieben des restlichen Stacks kann komplex sein.
Anmerkung
Es hat sich bewährt, nur auf Operationen auf der Datenebene, nicht auf Operationen auf der Steuerebene zu setzen, da einige Operationen auf Steuerebene bei Regionsausfällen beeinträchtigt sein können.
Weitere Informationen finden Sie im AWS Blogbeitrag Build resilient applications with Amazon DynamoDB global tables: Part 4.
Regelmäßiger Test aller Aspekte des Runbooks, einschließlich Evakuierungen von Regionen. Ein nicht getestetes Runbook ist ein unzuverlässiges Runbook.
Erwägung des Einsatzes von Resilience Hub, um die Widerstandsfähigkeit Ihrer gesamten Anwendung (einschließlich globaler Tabellen) zu bewerten. Das Hub bietet in seinem Dashboard einen umfassenden Überblick über die Widerstandsfähigkeit Ihres gesamten Anwendungsportfolios.
Erwägen Sie, ARC Eignungsprüfungen zu verwenden, um die aktuelle Konfiguration Ihrer Anwendung zu bewerten und etwaige Abweichungen von den bewährten Methoden nachzuverfolgen.
Beim Schreiben einer Zustandsprüfung für die Verwendung mit Route 53 oder Global Accelerator reicht es nicht aus, mittels Ping festzustellen, dass der DynamoDB-Endpunkt aktiv ist. Dies deckt nicht die vielen Fehlermodi ab, z. B. IAM Konfigurationsfehler, Probleme bei der Codebereitstellung, Fehler im Stack außerhalb von DynamoDB, überdurchschnittliche Lese- oder Schreiblatenzen usw. Es empfiehlt sich, eine Reihe von Aufrufen durchzuführen, die einen vollständigen Datenbankfluss gewährleisten.
Häufig gestellte Fragen (FAQ) für die Bereitstellung globaler Tabellen
Was sind nützliche Prinzipien für die allgemeine Verwendung globaler DynamoDB-Tabellen?
Bei globalen DynamoDB-Tabellen gibt es nur sehr wenige Steuerungselemente, dennoch sind einige Überlegungen notwendig. Sie müssen Ihren Schreibmodus, Ihr Weiterleitungsmodell und Ihre Evakuierungsprozesse festlegen. Sie müssen Ihre Anwendung in jeder Region instrumentieren und bereit sein, Ihre Weiterleitung anzupassen oder eine Evakuierung durchzuführen, um die globale Integrität zu erhalten. Dies zahlt sich aus, da Sie auf diese Weise einen global verteilten Datensatz mit niedrigen Latenzzeiten beim Lesen und Schreiben und ein Service Level Agreement von 99,999 % erhalten.
Wie hoch sind die Preise für globale Tabellen?
Schreibvorgänge in eine herkömmliche DynamoDB-Tabelle werden in Schreibkapazitätseinheiten (WCUsfür bereitgestellte Tabellen) oder Schreibanforderungseinheiten (WRUsfür On-Demand-Tabellen) berechnet. Beim Schreiben eines 5-KB-Elements fällt eine Gebühr von 5 Einheiten an. Schreibvorgänge in eine globale Tabelle werden in replizierten Schreibkapazitätseinheiten (für bereitgestellte Tabellen) oder replizierten Schreibanforderungseinheiten (rWCUsrWRUs, für On-Demand-Tabellen) berechnet.
Die rWCUs und rWRUs beinhalten die Kosten für die Streaming-Infrastruktur, die für die Verwaltung der Replikation erforderlich ist. Daher sind sie 50% teurer als WCUs undWRUs. Es fallen Gebühren für regionsübergreifende Datenübertragungen an.
Gebühren für replizierte Schreibeinheiten fallen in jeder Region an, in die das Element direkt oder im Zuge einer Replikation geschrieben wird.
Das Schreiben in einen globalen Sekundärindex (GSI) wird als lokaler Schreibvorgang betrachtet und verwendet reguläre Schreibeinheiten.
Derzeit ist keine reservierte Kapazität verfügbar. rWCUs Der Kauf von reservierter Kapazität kann für Tabellen mit GSIs verbrauchten Schreibeinheiten dennoch von Vorteil sein.
Der ursprüngliche Bootstrap beim Hinzufügen einer neuen Region zu einer globalen Tabelle wird wie eine Wiederherstellung pro GB wiederhergestellter Daten berechnet, zuzüglich der Gebühren für die regionsübergreifende Datenübertragung.
Welche Regionen werden von globalen Tabellen unterstützt?
Global Tables Version 2019.11.21 (aktuell) ist in den meisten Regionen verfügbar. Die aktuelle Liste finden Sie in der Drop-down-Liste „Region“ in der DynamoDB-Konsole, wenn Sie ein Replikat hinzufügen.
Wie GSIs wird mit globalen Tabellen umgegangen?
Wenn Sie in Global Tables Version 2019.11.21 (aktuell) eine GSI in einer Region erstellen, wird sie automatisch in anderen teilnehmenden Regionen erstellt und automatisch aufgefüllt.
Wie stoppe ich die Replikation einer globalen Tabelle?
Sie können eine Replikattabelle genauso löschen, wie Sie jede andere Tabelle löschen würden. Wenn Sie die globale Tabelle löschen, wird die Replikation in die betreffende Region beendet und die in dieser Region gespeicherte Tabellenkopie wird gelöscht. Sie können die Replikation jedoch nicht stoppen, solange Sie Kopien der Tabelle als unabhängige Entitäten behalten, und Sie können die Replikation auch nicht unterbrechen.
Wie interagieren DynamoDB-Streams mit globalen Tabellen?
Jede globale Tabelle erzeugt einen unabhängigen Stream, der auf allen ihren Schreibvorgängen basiert, unabhängig davon, wo diese gestartet wurden. Sie können wählen, ob Sie den DynamoDB-Stream in einer Region oder in allen Regionen (unabhängig voneinander) nutzen möchten. Wenn Sie lokale Schreibvorgänge, aber keine replizierten Schreibvorgänge verarbeiten möchten, können Sie jedem Element Ihr eigenes Regionsattribut hinzufügen, um die schreibende Region zu identifizieren. Sie können dann einen Lambda-Ereignisfilter verwenden, um die Lambda-Funktion nur für Schreibvorgänge in der lokalen Region aufzurufen. Dies ist bei Einfügungen und Aktualisierungen hilfreich, aber leider nicht bei Löschvorgängen.
Wie werden Transaktionen in globalen Tabellen gehandhabt?
Transaktionsoperationen bieten Atomarität, Konsistenz, Isolierung und Haltbarkeit (ACID) nur innerhalb der Region, in der der Schreibvorgang ursprünglich stattgefunden hat. Regionsübergreifende Transaktionen werden in globalen Tabellen nicht unterstützt. 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 dann in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden.
Wie interagieren globale Tabellen mit dem DynamoDB Accelerator-Cache ()DAX?
Globale Tabellen DAX werden umgangen, indem DynamoDB direkt aktualisiert wird, sodass es sich DAX nicht bewusst ist, dass es veraltete Daten enthält. Der DAX Cache wird nur aktualisiert, wenn der Cache abläuft. TTL
Werden Tags auf Tabellen weitergegeben?
Nein, Tags werden nicht automatisch weitergegeben.
Sollte ich Tabellen in allen Regionen sichern oder nur in einer?
Die Antwort hängt davon ab, zu welchem Zweck Sie die Sicherung erstellen. Wenn Sie die Beständigkeit Ihrer Daten sicherstellen möchten, bietet DynamoDB diesen Schutz bereits. Der Service gewährleistet Datenbeständigkeit. Wenn Sie einen Snapshot für historische Aufzeichnungen aufbewahren möchten (beispielsweise um regulatorische Anforderungen zu erfüllen), sollte eine Sicherung in einer Region ausreichen. Sie können das Backup in weitere Regionen kopieren, indem Sie AWS Backup Wenn Sie irrtümlich gelöschte oder geänderte Daten wiederherstellen möchten, verwenden Sie DynamoDB point-in-time recovery (PITR) in einer Region.
Wie stelle ich globale Tabellen bereit mit? AWS CloudFormation
CloudFormation stellt eine DynamoDB-Tabelle und eine globale Tabelle als zwei separate Ressourcen dar: AWS::DynamoDB::Table und. AWS::DynamoDB::GlobalTable Ein Ansatz besteht darin, alle Tabellen, die potenziell global sein können, mithilfe des GlobalTable-Konstrukts zu erstellen. Sie können sie dann zunächst als eigenständige Tabellen beibehalten und später bei Bedarf Regionen hinzufügen.
CloudFormationIn wird jede globale Tabelle unabhängig von der Anzahl der Replikate von einem einzelnen Stack in einer einzigen Region gesteuert. Wenn Sie Ihre Vorlage bereitstellen, werden alle Replikate als Teil eines einzigen Stack-Vorgangs CloudFormation erstellt und aktualisiert. Sie sollten dieselbe AWS: :DynamoDB:: GlobalTable -Ressource nicht in mehreren Regionen bereitstellen. Dies führt zu Fehlern und wird nicht unterstützt. Wenn Sie Ihre Anwendungsvorlage in mehreren Regionen bereitstellen, können Sie Bedingungen verwenden, um die AWS::DynamoDB::GlobalTable-Ressource in einer einzigen Region zu erstellen. Alternativ können Sie Ihre AWS::DynamoDB::GlobalTable-Ressourcen in einem von Ihrem Anwendungs-Stack getrennten Stack definieren und sicherstellen, dass er in einer einzigen Region bereitgestellt wird.
Wenn Sie eine reguläre Tabelle haben und diese in eine globale Tabelle konvertieren und gleichzeitig verwalten möchten, legen Sie die Löschrichtlinie auf Retain fest, entfernen Sie die Tabelle aus dem Stapel, konvertieren Sie die Tabelle in eine globale Tabelle in der Konsole und importieren Sie dann die globale Tabelle als neue Ressource in den Stack. CloudFormation
Die kontoübergreifende Replikation wird zu diesem Zeitpunkt nicht unterstützt.
