Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
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 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
attributsaws:rep:deleting
aws: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 ofaws:rep:deleting
aws: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:UpdateGlobalTableversion
autorisations 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
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 :
|
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. |
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)
-
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.