Versions des tables globales DynamoDB
Deux versions des tables globales DynamoDB sont disponibles : la version 2019.11.21 (actuelle) et la version 2017.11.29 (héritée). Nous recommandons d’utiliser la version 2019.11.21 (actuelle) des tables globales, car elle est plus facile à utiliser, est prise en charge dans un plus grand nombre de régions et coûte moins cher pour la plupart des charges de travail que la version 2017.11.29 (héritée).
Détermination de la version d’une table globale
Détermination de la version à l’aide de l’AWS CLI
Identification d’une réplica de table globale de la version 2019.11.21 (actuelle)
Pour déterminer si une table est une réplica de table globale 2019.11.21 (actuelle), appelez la commande describe-table de la table. Si la sortie contient l’attribut GlobalTableVersion dont la valeur est « 2019.11.21 », la table est un réplica de table globale de la version 2019.11.21 (actuelle).
Exemple de commande CLI pour describe-table :
aws dynamodb describe-table \ --table-name users \ --region us-east-2
La sortie (abrégée) contient l’attribut GlobalTableVersion dont la valeur est « 2019.11.21 ». La table est donc un réplica de table globale de la version 2019.11.21 (actuelle).
{ "Table": { "AttributeDefinitions": [ { "AttributeName": "id", "AttributeType": "S" }, { "AttributeName": "name", "AttributeType": "S" } ], "TableName": "users", ... "GlobalTableVersion": "2019.11.21", "Replicas": [ { "RegionName": "us-west-2", "ReplicaStatus": "ACTIVE", } ], ... } }
Identification d’un réplica de table version 2017.11.29 (héritée)
La version 2017.11.29 (héritée) des tables globales utilise un ensemble de commandes dédié pour la gestion globale des tables. Pour déterminer si une table est un réplica de tables globales version 2017.11.29 (actuelle), invoquez la commande describe-global-table pour la table. Si vous recevez une réponse positive, la table est un réplica de table globale de la version 2017.11.29 (héritée). Si la commande describe-global-table renvoie une erreur GlobalTableNotFoundException, la table n’est pas un réplica de la version 2017.11.29 (héritée).
Exemple de commande CLI pour describe-global-table :
aws dynamodb describe-global-table \ --table-name users \ --region us-east-2
La commande renvoie une réponse positive, de sorte que la table est un réplica de table globale de la version 2017.11.29 (héritée).
{ "GlobalTableDescription": { "ReplicationGroup": [ { "RegionName": "us-west-2" }, { "RegionName": "us-east-2" } ], "GlobalTableArn": "arn:aws:dynamodb::123456789012:global-table/users", "CreationDateTime": "2025-06-10T13:55:53.630000-04:00", "GlobalTableStatus": "ACTIVE", "GlobalTableName": "users" } }
Détermination de la version à l’aide de la console DynamoDB
Pour identifier la version d’un réplica de table globale, effectuez les opérations suivantes :
-
Ouvrez la console DynamoDB à l’adresse https://console.aws.amazon.com/dynamodb/home
. -
Dans le volet de navigation sur le côté gauche de la console, choisissez Tables.
-
Choisissez la table dont vous souhaitez identifier la version des tables globales.
-
Choisissez l’onglet Tables globales.
La section Récapitulatif affiche la version des tables globales utilisée.
Différences de comportement entre les versions héritées 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) utilise moins de capacité d’écriture pour plusieurs opérations DynamoDB que la version 2017.11.29 (héritée), et est donc plus rentable pour la plupart des clients. Les différences de ces opérations DynamoDB sont les suivantes :
-
L’invocation de PutItem pour un élément de 1 Ko dans une région et sa réplication dans d’autres régions nécessitent 2 rWRU par région pour la version 2017.11.29 (héritée), mais 1 seule rWRU pour la version 2019.11.21 (actuelle).
-
L’invocation de UpdateItem pour un élément de 1 Ko nécessite 2 rWRU par région de destination pour la version 2017.11.29 (héritée), mais 1 seule rWRU pour les régions source et destination pour la version 2019.11.21 (actuelle).
-
L’invocation de DeleteItem pour un élément de 1 Ko nécessite 1 rWRU dans la région source et 2 rWRU par région de destination pour la version 2017.11.29 (héritée), mais 1 seule rWRU pour les régions source ou destination pour la version 2019.11.21 (actuelle).
Le tableau suivant montre la consommation rWRU des tables 2017.11.29 (ancienne) et 2019.11.21 (actuelle) pour un élément de 1 Ko dans deux régions.
Opération 2017.11.29 (héritée) 2019.11.21 (actuelle) Economie PutItem 4 rWRU 2 rWRU 50 % UpdateItem 3 rWRU 2 rWRU 33 % DeleteItem 3 rWRU 2 rWRU 33 % -
-
La version 2017.11.29 (héritée) n’est disponible que dans 11 Régions AWS. Cependant, la version 2019.11.21 (actuelle) est disponible dans toutes les Régions AWS.
-
Vous créez des tables globales de la version 2017.11.29 (héritée) en créant d’abord un ensemble de tables régionales vides, puis en invoquant l’API CreateGlobalTable pour former la table globale. Vous créez des tables globales de la version 2019.11.21 (actuelle) en appelant l’API UpdateTable pour ajouter un réplica à une table régionale existante.
-
La version 2017.11.29 (héritée) vous oblige à vider tous les réplicas de la table avant d’ajouter un réplica 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éplicas dans les régions d’une table contenant déjà des données.
-
La version 2017.11.29 (héritée) utilise l’ensemble d’API de plan de contrôle dédié suivant pour gérer les réplicas :
La version 2019.11.21 (actuelle) utilise les API DescribeTable et UpdateTable pour gérer les réplicas.
-
la version 2017.11.29 (héritée) 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 (héritée) renseigne et met à jour les attributs
aws:rep:deleting,aws:rep:updateregionetaws:rep:updatetime. La version 2019.11.21 (actuelle) ne renseigne ni ne met à jour ces attributs. -
La version 2017.11.29 (héritée) ne synchronise pas les paramètres Utilisation de la durée de vie (TTL) dans DynamoDB entre les réplicas. La version 2019.11.21 (actuelle) synchronise les paramètres TTL entre les réplicas.
-
la version 2017.11.29 (héritée) ne réplique pas les suppressions TTL vers d’autres réplicas. La version 2019.11.21 (actuelle) réplique les suppressions TTL dans tous les réplicas.
-
La version 2017.11.29 (héritée) ne synchronise pas les paramètres d’autoscaling entre les réplicas. La version 2019.11.21 (actuelle) synchronise les paramètres d’autoscaling entre les réplicas.
-
La version 2017.11.29 (héritée) ne synchronise pas les paramètres d’index secondaires globaux (GSI) entre les réplicas. La version 2019.11.21 (actuelle) synchronise les paramètres GSI entre les réplicas.
-
La version 2017.11.29 (héritée) ne synchronise pas les paramètres de chiffrement au repos entre les réplicas. La version 2019.11.21 (actuelle) synchronise les paramètres de chiffrement au repos entre les réplicas.
-
La version 2017.11.29 (héritée) publie la métrique
PendingReplicationCount. La version 2019.11.21 (actuelle) ne publie pas cette métrique.
Mise à niveau vers la version actuelle
Autorisations requises pour la mise à niveau des tables globales
Pour effectuer une mise à niveau vers la version 2019.11.21 (actuelle), vous devez disposer d’autorisations dynamodb:UpdateGlobalTableversion dans toutes les régions avec des réplicas. Ces autorisations s’ajoutent aux autorisations nécessaires pour accéder à la console DynamoDB et afficher les tables.
La politique IAM suivante accorde des autorisations pour mettre à niveau 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 des autorisations pour mettre à niveau uniquement la table globale Music, avec des réplicas 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
-
Tous les réplicas 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éplicas.
-
Au cours du processus de mise à niveau, la valeur de TableStatus passera de
ACTIVEàUPDATING. Vous pouvez consulter le statut de la table en invoquant l’API DescribeTable ou en utilisant la vue Tables dans le . -
L’autoscaling 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 la capacité provisionné avec autoscaling pendant la mise à niveau, vous devez augmenter le débit minimum de lecture et d’écriture de vos politiques pour tenir compte des augmentations attendues du trafic et éviter toute limitation pendant la mise à niveau.
-
La métrique
ReplicationLatencypeut signaler temporairement les pics de latence ou arrêter de signaler les données métriques pendant le processus de mise à niveau. Pour plus d’informations, consultez ReplicationLatency. -
Lorsque le processus de mise à niveau est terminé, l’état de votre table revient à
ACTIVE.
Comportement de DynamoDB Streams avant, pendant et après la mise à niveau
| Opération | Région de réplica | Comportement avant la mise à niveau | Comportement pendant la mise à niveau | Comportement après la mise à niveau |
|---|---|---|---|---|
Placement ou mise à jour |
Source |
La population d’horodatage se produit à l’aide de UpdateItem. | La population d’horodatage se produit à l’aide de PutItem. | Aucun horodatage visible par le client n’est généré. |
Deux enregistrements de flux sont générés. Le premier enregistrement contient les attributs écrits par le client. Le deuxième enregistrement contient les attributs aws:rep:*. |
Deux enregistrements de flux sont générés. Le premier enregistrement contient les attributs écrits par le client. Le deuxième enregistrement contient les attributs aws:rep:*. |
Un seul enregistrement de flux contenant les attributs écrits par le client est généré. | ||
| Deux rWCU sont utilisées pour chaque écriture du client. | Deux rWCU sont utilisées pour chaque écriture du client. | Une rWCU est utilisée pour chaque écriture du client. | ||
Les métriques ReplicationLatency et PendingReplicationCount sont publiées dans CloudWatch. |
Les métriques ReplicationLatency et PendingReplicationCount sont publiées dans CloudWatch. |
La métrique ReplicationLatency est publiée dans CloudWatch. |
||
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 de flux est généré, qui contient à la fois les attributs écrits par le client et les attributs aws:rep:*. |
Un seul enregistrement de flux est généré, qui contient à la fois les attributs écrits par le client et les attributs aws:rep:*. |
Un seul enregistrement de flux est généré, qui contient uniquement les attributs écrits par le client et aucun attributs de réplication. | ||
| Une rWCU est utilisée si l’élément existe dans la région de destination. Deux rWCU sont utilisées si l’élément n’existe pas dans la région de destination. | Une rWCU est utilisée si l’élément existe dans la région de destination. Deux rWCU sont utilisées si l’élément n’existe pas dans la région de destination. | Une rWCU est utilisée pour chaque écriture du client. | ||
Les métriques ReplicationLatency et PendingReplicationCount sont publiées dans CloudWatch. |
Les métriques ReplicationLatency et PendingReplicationCount sont publiées dans CloudWatch. |
La métrique ReplicationLatency est publiée dans CloudWatch. |
||
Suppression |
Source |
Supprimez tout élément dont l’horodatage est plus petit à l’aide de DeleteItem. | Supprimez tout élément dont l’horodatage est plus petit à l’aide de DeleteItem. | Supprimez tout élément dont l’horodatage est plus petit à l’aide de DeleteItem. |
Un seul enregistrement de flux est généré, qui contient à la fois les attributs écrits par le client et les attributs aws:rep:*. |
Un seul enregistrement de flux est généré, qui contient à la fois les attributs écrits par le client et les attributs aws:rep:*. |
Un seul enregistrement de flux est généré, qui contient les attributs écrits par le client. | ||
| Une rWCU est utilisée pour chaque suppression du client. | Une rWCU est utilisée pour chaque suppression du client. | Une rWCU est utilisée pour chaque suppression du client. | ||
Les métriques ReplicationLatency et PendingReplicationCount sont publiées dans CloudWatch. |
Les métriques ReplicationLatency et PendingReplicationCount sont publiées dans CloudWatch. |
La métrique ReplicationLatency est publiée dans CloudWatch. |
||
Destination |
Des suppressions en deux phases ont lieu :
|
Supprime l’élément à l’aide de DeleteItem. | Supprime l’élément à l’aide de DeleteItem. | |
Deux enregistrements de flux sont générés. Le premier enregistrement contient la modification apportée au champ aws:rep:deleting. Le deuxième enregistrement contient les attributs écrits par le client et les attributs aws:rep:*. |
Un seul enregistrement de flux est généré, qui contient les attributs écrits par le client. | Un seul enregistrement de flux est généré, qui contient les attributs écrits par le client. | ||
| Deux rWCU sont utilisés pour chaque suppression par un client. | Une rWCU est utilisée pour chaque suppression du client. | Une rWCU est utilisée pour chaque suppression du client. | ||
Les métriques ReplicationLatency et PendingReplicationCount sont publiées dans CloudWatch. |
La métrique ReplicationLatency est publiée dans CloudWatch. |
La métrique ReplicationLatency est publiée dans CloudWatch. |
Mise à jour vers la version 2019.11.21 (actuelle)
Procédez comme suit pour mettre à jour la version des tables globales DynamoDB à l’aide de la AWS Management Console.
Pour mettre à niveau des tables globales vers la version 2019.11.21 (actuelle)
-
Ouvrez la console DynamoDB à l’adresse https://console.aws.amazon.com/dynamodb/home
. -
Dans le volet de navigation situé sur le côté gauche de la console, choisissez Tables, puis sélectionnez la table globale à mettre à niveau vers la version 2019.11.21 (actuelle).
-
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 est la version 2019.11.21.