Différences de comportement entre les versions anciennes et actuelles Conditions préalables à la mise à niveau Autorisations requises À quoi s'attendre lors de la mise à niveau Comportement de DynamoDB Streams Mise à niveau vers la version 2019.11.21 (actuelle)

Mise à niveau de vos tables globales DynamoDB de la version 2017.11.29 (ancienne) à la version 2019.11.21 (actuelle)

Note

Deux versions des tables globales DynamoDB sont disponibles : Global Tables version 2019.11.21 (actuelle) et. Tableaux globaux version 2017.11.29 (ancienne version) Les clients doivent utiliser la version 2019.11.21 (actuelle) dans la mesure du possible, car elle offre une plus grande flexibilité, une efficacité accrue et consomme moins de capacité d'écriture que la version 2017.11.29 (ancienne). Pour déterminer la version que vous utilisez, voirDéterminer la version de la table globale DynamoDB que vous utilisez.

Cette section explique comment mettre à niveau vos tables globales vers la version 2019.11.21 (actuelle) à l'aide de la console DynamoDB. La mise à niveau de la version 2017.11.29 (ancienne) vers la version 2019.11.21 (actuelle) est une action ponctuelle et vous ne pouvez pas l'annuler. Actuellement, vous pouvez mettre à niveau les tables globales uniquement à l'aide de la console.

Rubriques

Différences de comportement entre les versions anciennes et actuelles
Conditions préalables à la mise à niveau
Autorisations requises
À quoi s'attendre lors de la mise à niveau
Comportement de DynamoDB Streams
Mise à niveau vers la version 2019.11.21 (actuelle)

Différences de comportement entre les anciennes versions et les versions actuelles

La liste suivante décrit les différences de comportement entre les versions héritées et actuelles des tables globales.

la version 2019.11.21 (actuelle) consomme moins de capacité d'écriture pour plusieurs opérations DynamoDB par rapport à la version 2017.11.29 (ancienne) et est donc plus rentable pour la plupart des clients. Les différences entre ces opérations DynamoDB sont les suivantes :

L'appel PutItemd'un élément de 1 Ko dans une région et sa réplication vers d'autres régions nécessitent 2 r WRUs par région pour le 29 novembre 2017 (ancien), mais seulement 1 RWru pour le 21 novembre 2019 (actuel).
L'invocation UpdateItemd'un élément de 1 Ko nécessite 2 r WRUs dans la région source et 1 RWru par région de destination pour le 29 novembre 2017 (ancienne), mais un seul RWru pour les régions source et de destination pour le 21 novembre 2019 (actuel).
L'appel DeleteItemd'un élément de 1 Ko nécessite 1 RWru dans la région source et 2 r WRUs par région de destination pour le 29 novembre 2017 (ancien), mais un seul RWru pour la région source ou de destination pour le 21 novembre 2019 (actuel).

Le tableau suivant montre la consommation de RWru des tables du 29 novembre 2017 (ancienne version) et du 21 novembre 2019 (actuelle) pour un article de 1 Ko dans deux régions.

Opération	2017.11.29 (Héritage)	2019.11.21 (actuel)	Economie
PutItem	4 r WRUs	2 ou 3 WRUs	50%
UpdateItem	3 r WRUs	2 ou 3 WRUs	33 %
DeleteItem	3 r WRUs	2 ou 3 WRUs	33 %

la version 2017.11.29 (Legacy) n'est disponible qu'en 11. Régions AWS Cependant, la version 2019.11.21 (actuelle) est disponible dans tous les. Régions AWS
Vous créez les tables globales de la version 2017.11.29 (Legacy) en créant d'abord un ensemble de tables régionales vides, puis en invoquant l'CreateGlobalTableAPI pour former la table globale. Vous créez des tables globales de la version 2019.11.21 (Current) en appelant l'UpdateTableAPI pour ajouter une réplique à une table régionale existante.
la version 2017.11.29 (Legacy) vous oblige à vider toutes les répliques de la table avant d'ajouter une réplique dans une nouvelle région (y compris lors de la création). La version 2019.11.21 (actuelle) vous permet d'ajouter et de supprimer des répliques dans les régions d'une table contenant déjà des données.
la version 2017.11.29 (Legacy) utilise l'ensemble de plans de contrôle dédié suivant APIs pour gérer les répliques :
la version 2019.11.21 (Current) utilise le DescribeTableet UpdateTable APIs pour gérer les répliques.
la version 2017.11.29 (Legacy) publie deux enregistrements DynamoDB Streams pour chaque écriture. La version 2019.11.21 (actuelle) ne publie qu'un seul enregistrement DynamoDB Streams pour chaque écriture.
la version 2017.11.29 (Legacy) renseigne et met à jour les aws:rep:updatetime attributs aws:rep:deletingaws:rep:updateregion, et. La version 2019.11.21 (actuelle) ne renseigne ni ne met à jour ces attributs.
la version 2017.11.29 (Legacy) ne synchronise pas les Utilisation du temps de vie (TTL) dans DynamoDB paramètres entre les répliques. La version 2019.11.21 (actuelle) synchronise les paramètres TTL entre les répliques.
la version 2017.11.29 (Legacy) ne réplique pas les suppressions TTL vers d'autres répliques. La version 2019.11.21 (actuelle) réplique les suppressions TTL sur toutes les répliques.
la version 2017.11.29 (Legacy) ne synchronise pas les paramètres de mise à l'échelle automatique entre les répliques. La version 2019.11.21 (actuelle) synchronise les paramètres de mise à l'échelle automatique entre les répliques.
la version 2017.11.29 (Legacy) ne synchronise pas les paramètres de l'index secondaire global (GSI) entre les répliques. La version 2019.11.21 (Current) synchronise les paramètres GSI entre les répliques.
la version 2017.11.29 (Legacy) ne synchronise pas les paramètres de chiffrement au repos entre les répliques. La version 2019.11.21 (actuelle) synchronise les paramètres de chiffrement au repos entre les répliques.
la version 2017.11.29 (Legacy) publie la PendingReplicationCount métrique. La version 2019.11.21 (Current) ne publie pas cette métrique.

Conditions préalables à la mise à niveau

Avant de commencer la mise à niveau vers la version 2019.11.21 (actuelle) des tables globales, vous devez remplir les conditions préalables suivantes :

Utilisation du temps de vie (TTL) dans DynamoDBles paramètres des répliques sont cohérents d'une région à l'autre.
Les définitions de l'indice secondaire global (GSI) sur les répliques sont cohérentes d'une région à l'autre.
Les paramètres de chiffrement au repos des répliques sont cohérents d'une région à l'autre.
Le dimensionnement automatique DynamoDB est WCUs activé pour toutes les répliques, ou le mode capacité à la demande est activé pour toutes les répliques.
Les applications ne nécessitent pas la présence des aws:rep:updatetime attributs of aws:rep:deletingaws:rep:updateregion, et dans les éléments du tableau.

Autorisations requises pour la mise à niveau des tables globales

Pour passer à la version 2019.11.21 (actuelle), vous devez disposer d'dynamodb:UpdateGlobalTableversionautorisations dans toutes les régions dotées de répliques. Ces autorisations sont requises en plus des autorisations nécessaires pour accéder à la console DynamoDB et consulter les tables.

La politique IAM suivante autorise la mise à niveau de n'importe quelle table globale vers la version 2019.11.21 (actuelle).


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

La politique IAM suivante accorde l'autorisation de mettre à niveau uniquement la table Music globale contenant des répliques dans deux régions vers la version 2019.11.21 (actuelle).


{
    "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"
            ]
        }
    ]
}

À quoi s'attendre lors de la mise à niveau

Toutes les répliques de tables globales continueront à traiter le trafic de lecture et d'écriture pendant la mise à niveau.
Le processus de mise à niveau prend entre quelques minutes et plusieurs heures selon la taille de la table et le nombre de répliques.
Au cours du processus de mise à niveau, la valeur de TableStatuspassera de ACTIVE àUPDATING. Vous pouvez consulter l'état de la table en appelant l'DescribeTableAPI ou en utilisant la vue Tables de la console DynamoDB.
Le dimensionnement automatique n'ajustera pas les paramètres de capacité provisionnée pour une table globale pendant la mise à niveau de la table. Nous vous recommandons vivement de configurer la table en mode capacité à la demande lors de la mise à niveau.
Si vous choisissez d'utiliser le mode capacité allouée avec mise à l'échelle automatique lors de la mise à niveau, vous devez augmenter le débit minimum de lecture et d'écriture de vos politiques afin de tenir compte des augmentations de trafic attendues afin d'éviter toute limitation pendant la mise à niveau.
La ReplicationLatency métrique peut signaler temporairement les pics de latence ou arrêter de signaler les données métriques pendant le processus de mise à niveau. VoirReplicationLatency, pour plus d'informations.
Une fois le processus de mise à niveau terminé, le statut de votre table passe àACTIVE.

Comportement de DynamoDB Streams avant, pendant et après la mise à niveau

Mise à niveau vers la version 2019.11.21 (actuelle)

Procédez comme suit pour mettre à niveau votre version des tables globales DynamoDB à l'aide du. AWS Management Console

Pour mettre à niveau les tables globales vers la version 2019.11.21 (actuelle)

Ouvrez la console DynamoDB à la maison. https://console.aws.amazon.com/dynamodb/
Dans le volet de navigation sur le côté gauche de la console, choisissez Tables, puis sélectionnez la table globale que vous souhaitez mettre à niveau vers la version 2019.11.21 (Current).
Choisissez l'onglet Tables globales.
Choisissez Update version (Mettre à jour la version).
Lisez et acceptez les nouvelles exigences, puis choisissez Mettre à jour la version.
Une fois le processus de mise à niveau terminé, la version des tables globales qui apparaît sur la console devient 2019.11.21.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Détermination de la version

Facturation globale des tables

Opération	Région de réplique	Comportement avant mise à niveau	Comportement lors de la mise	Comportement après mise à niveau
Mettre ou mettre à jour	Source	La population d'horodatage se produit en utilisant. UpdateItem	La population d'horodatage se produit en utilisant. PutItem	Aucun horodatage visible par le client n'est généré.
		Deux enregistrements Streams sont générés. Le premier enregistrement contient les attributs écrits par le client. Le deuxième enregistrement contient les `aws:rep:*` attributs.	Deux enregistrements Streams sont générés. Le premier enregistrement contient les attributs écrits par le client. Le deuxième enregistrement contient les `aws:rep:*` attributs.	Un seul enregistrement Streams contenant les attributs écrits par le client est généré.
		Deux r WCUs sont consommés pour chaque écriture du client.	Deux r WCUs sont consommés pour chaque écriture du client.	Un RWCu est consommé pour chaque écriture du client.
		`ReplicationLatency`et `PendingReplicationCount` les statistiques sont publiées dans CloudWatch.	`ReplicationLatency`et `PendingReplicationCount` les statistiques sont publiées dans CloudWatch.	`ReplicationLatency`la métrique est publiée dans CloudWatch.
	Destination (Destination)	La réplication s'effectue à l'aide de PutItem.	La réplication s'effectue à l'aide de PutItem.	La réplication s'effectue à l'aide de PutItem.
		Un seul enregistrement Streams est généré, qui contient à la fois les attributs écrits par le client et les `aws:rep:*` attributs.	Un seul enregistrement Streams est généré, qui contient à la fois les attributs écrits par le client et les `aws:rep:*` attributs.	Un seul enregistrement Streams est généré, qui contient uniquement les attributs écrits par le client et aucun attribut de réplication.
		Un RWCu est consommé si l'article existe dans la région de destination. Deux r WCUs sont consommés si l'article n'existe pas dans la région de destination.	Un RWCu est consommé si l'article existe dans la région de destination. Deux r WCUs sont consommés si l'article n'existe pas dans la région de destination.	Un RWCu est consommé pour chaque écriture du client.
		`ReplicationLatency`et `PendingReplicationCount` les statistiques sont publiées dans CloudWatch.	`ReplicationLatency`et `PendingReplicationCount` les statistiques sont publiées dans CloudWatch.	`ReplicationLatency`la métrique est publiée dans CloudWatch.
Suppression	Source	Supprimez tout élément dont l'horodatage est plus petit en utilisant. DeleteItem	Supprimez tout élément dont l'horodatage est plus petit en utilisant. DeleteItem	Supprimez tout élément dont l'horodatage est plus petit en utilisant. DeleteItem
		Un seul enregistrement Streams est généré, qui contient à la fois les attributs écrits par le client et les `aws:rep:*` attributs.	Un seul enregistrement Streams est généré, qui contient à la fois les attributs écrits par le client et les `aws:rep:*` attributs.	Un seul enregistrement Streams est généré, qui contient les attributs écrits par le client.
		Un RWCU est consommé pour chaque suppression par un client.	Un RWCU est consommé pour chaque suppression par un client.	Un RWCU est consommé pour chaque suppression par un client.
		`ReplicationLatency`et `PendingReplicationCount` les statistiques sont publiées dans CloudWatch.	`ReplicationLatency`et `PendingReplicationCount` les statistiques sont publiées dans CloudWatch.	`ReplicationLatency`la métrique est publiée dans CloudWatch.
	Destination (Destination)	Des suppressions en deux phases ont lieu : Dans la phase 1, UpdateItem définit l'indicateur de suppression. Dans la phase 2, DeleteItem supprime l'élément.	Supprime l'élément à l'aide DeleteItem de.	Supprime l'élément à l'aide DeleteItem de.
		Deux enregistrements Streams sont générés. Le premier enregistrement contient la modification apportée au `aws:rep:deleting` champ. Le deuxième enregistrement contient les attributs écrits par le client et les `aws:rep:*` attributs.	Un seul enregistrement Stream est généré, qui contient les attributs écrits par le client.	Un seul enregistrement Stream est généré, qui contient les attributs écrits par le client.
		Deux r WCUs sont consommés pour chaque suppression par un client.	Un RWCU est consommé pour chaque suppression par un client.	Un RWCU est consommé pour chaque suppression par un client.
		`ReplicationLatency`et `PendingReplicationCount` les statistiques sont publiées dans CloudWatch.	`ReplicationLatency`la métrique est publiée dans CloudWatch.	`ReplicationLatency`la métrique est publiée dans CloudWatch.