Unterschiede im Verhalten älterer und aktueller Versionen Voraussetzungen für das Upgrade Erforderliche Berechtigungen Was ist während des Upgrades zu erwarten Verhalten von DynamoDB Streams Aktualisierung auf Version 2019.11.21 (aktuell)

Aktualisierung globaler Tabellen von der Legacy-Version (2017.11.29) auf die aktuelle Version (2019.11.21)

Es sind zwei Versionen von DynamoDB-Tabellen verfügbar: Global Tables Version 2019.11.21 (Aktuell) und. Globale Tabellen Version 2017.11.29 (veraltet) Kunden sollten nach Möglichkeit Version 2019.11.21 (aktuell) verwenden, da sie mehr Flexibilität und höhere Effizienz bietet und weniger Schreibkapazität verbraucht als Version 2017.11.29 (veraltet). Informationen darüber, welche Version Sie verwenden, finden Sie unter. Ermitteln der verwendeten Version der globalen Tabellen

In diesem Abschnitt wird beschrieben, wie Sie Ihre globalen Tabellen mithilfe der DynamoDB-Konsole auf Version 2019.11.21 (Aktuell) aktualisieren. Das Upgrade von Version 2017.11.29 (Legacy) auf Version 2019.11.21 (Aktuell) ist eine einmalige Aktion, die Sie nicht rückgängig machen können. Derzeit können Sie globale Tabellen nur über die Konsole aktualisieren.

Themen

Unterschiede im Verhalten älterer und aktueller Versionen
Voraussetzungen für das Upgrade
Erforderliche Berechtigungen
Was ist während des Upgrades zu erwarten
Verhalten von DynamoDB Streams
Aktualisierung auf Version 2019.11.21 (aktuell)

Unterschiede im Verhalten zwischen älteren und aktuellen Versionen

In der folgenden Liste werden die Verhaltensunterschiede zwischen der Legacy-Version und der aktuellen Version globaler Tabellen beschrieben.

Version 2019.11.21 (Aktuell) verbraucht im Vergleich zu Version 2017.11.29 (Legacy) weniger Schreibkapazität für mehrere DynamoDB-Operationen und ist daher für die meisten Kunden kostengünstiger. Die Unterschiede für diese DynamoDB-Operationen sind wie folgt:

Beim Aufrufen PutItemeines 1-KB-Elements in einer Region und beim Replizieren in andere Regionen sind 2 RWRUs pro Region für 2017.11.29 (Legacy), aber nur 1 RWRU für 2019.11.21 (Aktuell) erforderlich.
Der Aufruf UpdateItemeines 1-KB-Elements erfordert 2 RWRUs in der Quellregion und 1 RWRU pro Zielregion für 2017.11.29 (Legacy), aber nur 1 RWRU für Quell- und Zielregion für 2019.11.21 (Aktuell).
DeleteItemZum Aufrufen eines 1-KB-Elements sind 1 RWRU in der Quellregion und 2 RWRUs pro Zielregion für 2017.11.29 (Legacy) erforderlich, aber nur 1 RWRU sowohl für die Quell- als auch für die Zielregion für 2019.11.21 (Aktuell).

Die folgende Tabelle zeigt den RWRU-Verbrauch für die Tabellen 2017.11.29 (Legacy) und 2019.11.21 (aktuell).

Tabellen zum RWRU-Verbrauch von 2017.11.29 (Legacy) und 2019.11.21 (aktuell) für einen Artikel mit 1 KB in zwei Regionen
Operation	2017.11.29 (Legacy)	2019.11.21 (Aktuell)	Einsparungen
PutItem	4 RWRUs	2 RWRUs	50 %
UpdateItem	3 RWRUs	2 RWRUs	33%
DeleteItem	3 RWRUs	2 RWRUs	33%

Version 2017.11.29 (Legacy) ist nur in Version 11 verfügbar. AWS-Regionen Version 2019.11.21 (Aktuell) ist jedoch in allen Versionen verfügbar. AWS-Regionen
Sie erstellen globale Tabellen der Version 2017.11.29 (Legacy), indem Sie zuerst einen Satz leerer Regionaltabellen erstellen und dann die API aufrufen, um die CreateGlobalTableglobale Tabelle zu bilden. Sie erstellen globale Tabellen der Version 2019.11.21 (aktuell), indem Sie die UpdateTableAPI aufrufen, um einer vorhandenen Regionaltabelle ein Replikat hinzuzufügen.
Version 2017.11.29 (Legacy) erfordert, dass Sie alle Replikate in der Tabelle leeren, bevor Sie ein Replikat in einer neuen Region hinzufügen (auch während der Erstellung). Version 2019.11.21 (Aktuell) unterstützt Sie beim Hinzufügen und Entfernen von Replikaten zu Regionen in einer Tabelle, die bereits Daten enthält.
Version 2017.11.29 (Legacy) verwendet für die Verwaltung von Replikaten den folgenden speziellen Satz von APIs für die Steuerungsebene:
Version 2019.11.21 (aktuell) verwendet die APIs und zur Verwaltung von Replikaten. DescribeTable UpdateTable
Version 2017.11.29 (Legacy) veröffentlicht zwei DynamoDB Streams Streams-Datensätze für jeden Schreibvorgang. Version 2019.11.21 (Aktuell) veröffentlicht nur einen DynamoDB Streams Streams-Datensatz für jeden Schreibvorgang.
Version 2017.11.29 (Legacy) füllt und aktualisiert die Attribute, und. aws:rep:deleting aws:rep:updateregion aws:rep:updatetime Version 2019.11.21 (Aktuell) füllt oder aktualisiert diese Attribute nicht.
Version 2017.11.29 (Legacy) synchronisiert keine Einstellungen zwischen Replikaten. Zeit bis zum Leben (TTL) Version 2019.11.21 (aktuell) synchronisiert TTL-Einstellungen replikatsübergreifend.
Version 2017.11.29 (Legacy) repliziert TTL-Löschungen nicht auf andere Replikate. Version 2019.11.21 (aktuell) repliziert TTL-Löschungen auf alle Replikate.
Version 2017.11.29 (Legacy) synchronisiert die Auto Scaling-Einstellungen nicht replikatsübergreifend. Version 2019.11.21 (Aktuell) synchronisiert die Auto Scaling-Einstellungen zwischen Replikaten.
Version 2017.11.29 (Legacy) synchronisiert die Einstellungen für den globalen sekundären Index (GSI) nicht replikatsübergreifend. Version 2019.11.21 (Aktuell) synchronisiert GSI-Einstellungen replikatsübergreifend.
Version 2017.11.29 (Legacy) synchronisiert die Einstellungen für Verschlüsselung im Ruhezustand nicht replikatsübergreifend. Version 2019.11.21 (aktuell) synchronisiert die Einstellungen für Verschlüsselung im Ruhezustand zwischen Replikaten.
Version 2017.11.29 (Legacy) veröffentlicht die Metrik. PendingReplicationCount Version 2019.11.21 (Aktuell) veröffentlicht diese Metrik nicht.

Voraussetzungen für das Upgrade

Bevor Sie mit dem Upgrade auf Version 2019.11.21 (Current) Global Tables beginnen, müssen Sie die folgenden Voraussetzungen erfüllen:

Zeit bis zum Leben (TTL)Die Einstellungen für Replikate sind in allen Regionen konsistent.
Die Definitionen des globalen Sekundärindex (GSI) für Replikate sind in allen Regionen konsistent.
Die Einstellungen für die Verschlüsselung im Ruhezustand auf Replikaten sind in allen Regionen konsistent.
DynamoDB Auto Scaling ist für WCUs für alle Replikate aktiviert, oder der On-Demand-Kapazitätsmodus ist für alle Replikate aktiviert.
Für Anwendungen ist das Vorhandensein der Attribute vonaws:rep:deleting, aws:rep:updateregion und aws:rep:updatetime in Tabellenelementen nicht erforderlich.

Erforderliche Berechtigungen für das Upgrade globaler Tabellen

Für ein Upgrade auf Version 2019.11.21 (aktuell) benötigen Sie dynamodb:UpdateGlobalTableVersion Berechtigungen in allen Regionen mit Replikaten. Diese Berechtigungen sind zusätzlich zu den Berechtigungen erforderlich, die für den Zugriff auf die DynamoDB-Konsole und das Anzeigen von Tabellen erforderlich sind.

Die folgende IAM-Richtlinie gewährt Berechtigungen zum Upgrade jeder globalen Tabelle auf Version 2019.11.21 (aktuell).


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:UpdateGlobalTableVersion",
            "Resource": "*"
        }
    ]
}

Die folgende IAM-Richtlinie gewährt Berechtigungen, nur die Music globale Tabelle mit Replikaten in zwei Regionen auf Version 2019.11.21 (aktuell) zu aktualisieren.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:UpdateGlobalTableVersion",
            "Resource": [
                "arn:aws:dynamodb::123456789012:global-table/Music",
                "arn:aws:dynamodb:ap-southeast-1:123456789012:table/Music",
                "arn:aws:dynamodb:us-east-2:123456789012:table/Music"
            ]
        }
    ]
}

Was ist während des Upgrades zu erwarten

Alle globalen Tabellenreplikate verarbeiten während des Upgrades weiterhin Lese- und Schreibverkehr.
Der Upgrade-Vorgang dauert je nach Tabellengröße und Anzahl der Replikate zwischen einigen Minuten und mehreren Stunden.
Während des Upgrade-Vorgangs TableStatusändert sich der Wert von von ACTIVE aufUPDATING. Sie können den Status der Tabelle anzeigen, indem Sie die DescribeTableAPI aufrufen oder die Tabellenansicht in der DynamoDB-Konsole verwenden.
Auto Scaling passt die bereitgestellten Kapazitätseinstellungen für eine globale Tabelle nicht an, während die Tabelle aktualisiert wird. Es wird dringend empfohlen, die Tabelle während des Upgrades auf den On-Demand-Kapazitätsmodus einzustellen.
Wenn Sie während des Upgrades den Modus für bereitgestellte Kapazität mit Auto Scaling verwenden möchten, müssen Sie den Mindestdurchsatz für Lese- und Schreibvorgänge in Ihren Richtlinien erhöhen, um den erwarteten Anstieg des Datenverkehrs zu berücksichtigen und eine Drosselung während des Upgrades zu vermeiden.
Wenn der Upgrade-Vorgang abgeschlossen ist, ändert sich Ihr Tabellenstatus auf. ACTIVE

Verhalten von DynamoDB Streams vor, während und nach dem Upgrade

Aktualisierung auf Version 2019.11.21 (aktuell)

Führen Sie die folgenden Schritte aus, um Ihre Version der globalen DynamoDB-Tabellen mithilfe von zu aktualisieren. AWS Management Console

Um globale Tabellen auf Version 2019.11.21 (Aktuell) zu aktualisieren

Öffnen Sie die DynamoDB-Konsole unter https://console.aws.amazon.com/dynamodb/home.
Wählen Sie im Navigationsbereich auf der linken Seite der Konsole Tabellen und dann die globale Tabelle aus, für die Sie ein Upgrade auf Version 2019.11.21 (Aktuell) durchführen möchten.
Wählen Sie die Registerkarte Global Tables (Globale Tabellen) aus.
Wählen Sie Update version (Version aktualisieren) aus.
Lesen Sie sich die neuen Anforderungen durch und stimmen Sie ihnen zu, wählen Sie dann Update version Version aktualisieren.
Nach Abschluss des Upgrade-Vorgangs wird die Version der globalen Tabellen, die auf der Konsole angezeigt wird, auf 2019.11.21 geändert.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Bestimmen der Version

Arbeiten mit Lese- und Schreiboperationen

Operation	Region replizieren	Verhalten vor dem Upgrade	Verhalten während des Upgrades	Verhalten nach dem Upgrade
Platzieren oder aktualisieren	Quelle	Die Population mit Zeitstempeln erfolgt unter Verwendung von UpdateItem.	Die Population mit Zeitstempeln erfolgt unter Verwendung von. PutItem	Es wird kein sichtbarer Zeitstempel für den Kunden generiert.
		Zwei Streams-Datensätze werden generiert. Der erste Datensatz enthält die vom Kunden geschriebenen Attribute. Der zweite Datensatz enthält die `aws:rep:*` Attribute.	Zwei Streams-Datensätze werden generiert. Der erste Datensatz enthält die vom Kunden geschriebenen Attribute. Der zweite Datensatz enthält die `aws:rep:*` Attribute.	Es wird ein einziger Streams-Datensatz generiert, der die vom Kunden geschriebenen Attribute enthält.
		Für jeden Schreibvorgang durch den Kunden werden zwei RWCUs verbraucht.	Für jeden Schreibvorgang durch den Kunden werden zwei RWCUs verbraucht.	Für jeden Schreibvorgang durch den Kunden wird eine RWCu verbraucht.
		`ReplicationLatency`und `PendingReplicationCount` Metriken werden in CloudWatch veröffentlicht.	`ReplicationLatency`und `PendingReplicationCount` Metriken werden in veröffentlicht CloudWatch.	`ReplicationLatency`Die Metrik ist veröffentlicht in CloudWatch.
	Zieladresse	Die Replikation erfolgt mit PutItem.	Die Replikation erfolgt unter Verwendung von PutItem.	Die Replikation erfolgt unter Verwendung von PutItem.
		Es wird ein einziger Streams-Datensatz generiert, der sowohl die vom Kunden geschriebenen Attribute als auch die `aws:rep:*` Attribute enthält.	Es wird ein einziger Streams-Datensatz generiert, der sowohl die vom Kunden geschriebenen Attribute als auch die `aws:rep:*` Attribute enthält.	Es wird ein einziger Streams-Datensatz generiert, der nur die vom Kunden geschriebenen Attribute und keine Replikationsattribute enthält.
		Ein RWCu wird verbraucht, wenn das Element in der Zielregion vorhanden ist. Zwei RWCUs werden verbraucht, wenn der Artikel in der Zielregion nicht existiert.	Eine RWCu wird verbraucht, wenn der Artikel in der Zielregion vorhanden ist. Zwei RWCUs werden verbraucht, wenn der Artikel in der Zielregion nicht existiert.	Für jeden Schreibvorgang durch den Kunden wird eine RWCu verbraucht.
		`ReplicationLatency`und `PendingReplicationCount` Metriken werden in CloudWatch veröffentlicht.	`ReplicationLatency`und `PendingReplicationCount` Metriken werden in veröffentlicht CloudWatch.	`ReplicationLatency`Die Metrik ist veröffentlicht in CloudWatch.
Löschen	Quelle	Löschen Sie alle Elemente mit kleinerem Zeitstempel mithilfe von DeleteItem.	Löschen Sie alle Elemente mit kleinerem Zeitstempel mithilfe von. DeleteItem	Löschen Sie alle Elemente mit kleinerem Zeitstempel mithilfe von. DeleteItem
		Es wird ein einziger Streams-Datensatz generiert, der sowohl die vom Kunden geschriebenen Attribute als auch die `aws:rep:*` Attribute enthält.	Es wird ein einziger Streams-Datensatz generiert, der sowohl die vom Kunden geschriebenen Attribute als auch die `aws:rep:*` Attribute enthält.	Es wird ein einziger Streams-Datensatz generiert, der die vom Kunden geschriebenen Attribute enthält.
		Für jeden vom Kunden gelöschten Vorgang wird ein RWCu verbraucht.	Für jeden gelöschten Kunden wird eine RWCu verbraucht.	Für jeden gelöschten Kunden wird eine RWCu verbraucht.
		`ReplicationLatency`und `PendingReplicationCount` Metriken werden in CloudWatch veröffentlicht.	`ReplicationLatency`und `PendingReplicationCount` Metriken werden in veröffentlicht CloudWatch.	`ReplicationLatency`Die Metrik ist veröffentlicht in CloudWatch.
	Zieladresse	Löschungen finden in zwei Phasen statt: In Phase 1 wird das UpdateItem Löschkennzeichen gesetzt. DeleteItem Löscht in Phase 2 das Element.	Löscht das Element mit. DeleteItem	Löscht das Element mit. DeleteItem
		Es werden zwei Streams-Datensätze generiert. Der erste Datensatz enthält die Änderung des `aws:rep:deleting` Felds. Der zweite Datensatz enthält die vom Kunden geschriebenen Attribute und die `aws:rep:*` Attribute.	Es wird ein einziger Stream-Datensatz generiert, der die vom Kunden geschriebenen Attribute enthält.	Es wird ein einziger Stream-Datensatz generiert, der die vom Kunden geschriebenen Attribute enthält.
		Für jede Kundenlöschung werden zwei RWCUs verbraucht.	Für jede Kundenlöschung wird eine RWCu verbraucht.	Für jeden gelöschten Kunden wird eine RWCu verbraucht.
		`ReplicationLatency`und `PendingReplicationCount` Metriken werden in CloudWatch veröffentlicht.	`ReplicationLatency`Die Metrik ist veröffentlicht in CloudWatch.	`ReplicationLatency`Die Metrik ist veröffentlicht in CloudWatch.