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.
Bonnes pratiques et exigences pour la gestion des tables globales
À l'aide des tables globales Amazon DynamoDB, vous pouvez répliquer les données de vos tables d'une région à l'autre. AWS Pour garantir une réplication correcte des données, il est important que les tables de réplique et les index secondaires dans votre table globale aient des paramètres de capacité d'écriture identiques.
Pour plus de clarté, il peut être utile de ne pas mettre la région dans le nom d'une table qui pourrait un jour devenir une table globale.
Avertissement
Le nom de chaque table globale doit être unique au sein de votre AWS compte.
Version des tables globales
Pour déterminer la version de la table globale que vous utilisez, consultezDéterminer quelle version des tables globales vous utilisez.
Exigences pour la gestion de la capacité
Une table globale doit avoir une capacité de débit configurée de l'une des deux manières suivantes :
-
Mode de capacité à la demande, mesuré en unités de demande d'écriture répliquées (rWRU)
-
Mode de capacité allouée avec scalabilité automatique, mesurée en unités de capacité d'écriture répliquées (rWCU)
L'utilisation du mode de capacité allouée avec mise à l'échelle automatique ou du mode de capacité à la demande permet de s'assurer qu'une table globale a une capacité suffisante pour effectuer des écritures répliquées dans toutes les régions de la table globale.
Note
Passer du mode de capacité d'une table à l'autre dans une région quelconque change le mode pour tous les réplicas.
Déploiement des tables globales
Dans AWS CloudFormation, chaque table globale est contrôlée par une seule pile dans une seule région. Le nombre de réplicas n'a pas d'importance. Lorsque vous déployez votre modèle, CloudFormation vous créez/mettez à jour toutes les répliques dans le cadre d'une opération de pile unique. Vous ne devez donc pas déployer la même ressource AWS::DynamoDB::GlobalTable dans plusieurs régions. Cette opération n'est pas prise en charge et entraînera des erreurs.
Si vous déployez votre modèle d'application dans plusieurs régions, vous pouvez utiliser des conditions pour créer la ressource dans une seule région. Vous pouvez également choisir de définir vos ressources AWS::DynamoDB::GlobalTable dans une pile distincte de votre pile d'applications et vous assurer qu'elle n'est déployée que dans une seule région. Pour plus d'informations, voir Tableaux globaux dans CloudFormation
Une table DynamoDB est référencée par AWS::DynamoDB::Table et une table globale est désignée par AWS::DynamoDB::GlobalTable. En ce qui CloudFormation concerne, cela en fait essentiellement deux ressources différentes. Par conséquent, une approche consiste à créer toutes les tables susceptibles d'être globales à l'aide de la construction GlobalTable. Vous pouvez les conserver sous forme de tables autonomes pour commencer, puis les ajouter ultérieurement aux régions si nécessaire.
Si vous avez une table normale et que vous souhaitez la convertir en cours d'utilisation CloudFormation, il est recommandé de :
Définir la politique de suppression à conserver.
Retirer la table de la pile.
Convertir la table en table globale dans la console.
Importer la table globale en tant que nouvelle ressource dans la pile.
Note
La réplication entre comptes n'est pas prise en charge pour le moment.
Utilisation de tables globales pour aider à gérer une éventuelle panne de région
Vous pouvez posséder ou créer rapidement des copies indépendantes de votre pile d'exécution dans d'autres régions, chacune ayant accès à son point de terminaison DynamoDB local.
Utilisez Route53 ou AWS Global Accelerator pour vous rendre dans la région saine la plus proche. Vous pouvez également informer le client des différnts points de terminaison qu'il peut utiliser.
Effectuez des surveillances de l'état dans chaque région afin de déterminer de manière fiable tout problème lié à la pile, y compris une éventuelle dégradation de DynamoDB. Par exemple, ne vous contentez pas d'envoyer un ping pour indiquer que le point de terminaison DynamoDB est actif. Effectuez un appel qui garantit un flux de base de données complet et réussi.
Si la surveillance de l'état échoue, le trafic peut être acheminé vers d'autres régions (en mettant à jour l'entrée DNS avec Route53, en faisant en sorte que Global Accelerator achemine différemment ou en demandant au client de choisir un point de terminaison différent). Les tables globales ont un bon RPO (objectif de point de restauration), car les données sont synchronisées en permanence, et un bon RTO (objectif de temps de restauration), car les deux régions gardent toujours une table prête pour le trafic en lecture et en écriture.
Pour plus d'informations sur la surveillance de l'état, consultez les Types de surveillance de l'état.
Note
DynamoDB est un service de base sur lequel d'autres services fondent fréquemment leurs opérations de plan de contrôle. Il est donc peu probable que vous rencontriez un scénario dans lequel DynamoDB proposerait un service dégradé dans une région, et dans lequel les autres services n'en seraient pas affectés.
Sauvegarde des tables globales
Lors de la sauvegarde de tables globales, une sauvegarde des tables d'une région devrait suffire. La sauvegarde de toutes les tables de toutes les régions ne devrait pas être requise. Si l'objectif est de pouvoir récupérer des données supprimées ou modifiées par erreur, le PITR dans une région devrait suffire. De même, lors de la préservation d'un instantané à des fins d'historique, telles que des exigences réglementaires, une sauvegarde dans une région devrait suffire. Les données sauvegardées peuvent être répliquées dans plusieurs régions via AWS Backup.
Réplicas et calcul des unités d'écriture
Pour la planification, vous devez prendre le nombre d'écritures qu'une région effectuera et l'ajouter au nombre d'écritures effectuées pour chaque autre région. Cela est essentiel, car chaque écriture effectuée dans une région doit également l'être dans chaque région de réplica. Si vous ne disposez pas d'une capacité suffisante pour gérer toutes les écritures, des exceptions de capacité se produiront. En outre, les temps d'attente pour la réplication interrégionale augmenteront.
Par exemple, supposons que vous prévoyez 5 écritures par seconde sur votre table de réplica en Ohio, 10 écritures par seconde sur votre table de réplica en Virginie du Nord et 5 écritures par seconde sur votre table de réplica en Irlande. Dans ce cas, vous devez vous attendre à consommer 20 rWCU ou rWRU dans chaque région : Ohio, Virginie du Nord et Irlande. En d'autres termes, vous devez vous attendre à consommer 60 rWCU au total dans les trois régions.
Pour plus de détails sur la capacité allouée avec mise à l'échelle automatique et DynamoDB, consultez Gestion automatique de la capacité de débit avec la scalabilité automatique de DynamoDB.
Note
Si une table est exécutée en mode de capacité allouée avec mise à l'échelle automatique, la capacité d'écriture allouée est autorisée à flotter dans les paramètres de mise à l'échelle automatique de chaque région.
