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

Mise à niveau des tables globales vers la version actuelle (2019.11.21) à partir de l'ancienne version (2017.11.29)

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 quelle version des tables globales vous utilisez.

Cette section décrit 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
Conditions préalables à la mise à niveau
Autorisations nécessaires
À 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 que 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 RWRU par région pour le 29 novembre 2017 (ancien), mais un seul RWru pour le 21 novembre 2019 (actuel).
L'invocation UpdateItemd'un élément de 1 Ko nécessite 2 RWRU dans la région source et 1 RWru par région de destination pour le 29 novembre 2017 (ancienne), mais une seule RWru pour les régions source et de destination pour le 21 novembre 2019 (actuel).
L'invocation DeleteItemd'un élément de 1 Ko nécessite 1 RWru dans la région source et 2 RWRU par région de destination pour le 29 novembre 2017 (ancienne), mais une seule RWru pour la région source ou de destination pour le 21 novembre 2019 (actuel).

Le tableau suivant montre la consommation du RWru pour les tables du 29 novembre 2017 (ancien) et du 21 novembre 2019 (actuel).

Consommation 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 RWRU	2 RWRU	50%
UpdateItem	3 RWRU	2 RWRU	33 %
DeleteItem	3 RWRU	2 RWRU	33 %

La version 2017.11.29 (Legacy) n'est disponible que dans la version 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 du tableau 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 sur une table contenant déjà des données.
La version 2017.11.29 (Legacy) utilise l'ensemble dédié d'API de plan de contrôle suivant pour gérer les répliques :
La version 2019.11.21 (actuelle) utilise les UpdateTableAPI DescribeTableet 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 attributsaws:rep:deleting, aws:rep:updateregion et. aws:rep:updatetime La version 2019.11.21 (actuelle) ne renseigne ni ne met à jour ces attributs.
La version 2017.11.29 (Legacy) ne synchronise pas les Time to Live (TTL) 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 sur 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 (actuelle) 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 métrique. PendingReplicationCount La version 2019.11.21 (actuelle) ne publie pas cette métrique.

Conditions préalables à la mise à niveau

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

Time to Live (TTL)les 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 activé pour les WCU 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.
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 à l'adresse https://console.aws.amazon.com/dynamodb/home.
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 (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 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

Utilisation des opérations de lecture et d'écriture

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 RWCU sont consommées pour chaque écriture du client.	Deux RWCU sont consommées 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 RWCU sont consommées 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 RWCU sont consommées 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 RWCU sont consommées 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.