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.

Fonctionnement des tables globales DynamoDB

Les sections suivantes décrivent les concepts et les comportements des tables globales dans Amazon DynamoDB.

Concepts

Les tables globales sont une fonctionnalité de DynamoDB qui réplique les données des tables entre les régions. AWS

Une table répliquée (ou réplique) est une table DynamoDB qui fonctionne dans le cadre d'une table globale. Une table globale se compose d'au moins deux répliques de tables réparties dans différentes AWS régions. Chaque table globale ne peut comporter qu'une seule réplique par AWS région. Toutes les répliques d'une table globale partagent le même nom de table, le même schéma de clé primaire et les mêmes données d'élément.

Lorsqu'une application écrit des données dans une réplique d'une région, DynamoDB réplique automatiquement l'écriture sur toutes les autres répliques de la table globale. Pour en savoir plus sur la façon de commencer à utiliser des tables globales, consultez Tutoriels : Création de tables globales.

Versions

Deux versions des tables globales DynamoDB sont disponibles : la version 2019.11.21 (actuelle) et la version 2017.11.29 (ancienne). Vous devez utiliser la version 2019.11.21 (actuelle) dans la mesure du possible. Les informations contenues dans cette section de documentation concernent la version 2019.11.21 (actuelle). Pour de plus amples informations, veuillez consulter Déterminer la version d'une table globale.

Disponibilité

Les tables globales contribuent à améliorer la continuité de votre activité en facilitant la mise en œuvre d'une architecture de haute disponibilité multirégionale. Si la charge de travail d'une seule AWS région est altérée, vous pouvez déplacer le trafic de l'application vers une autre région et effectuer des lectures et des écritures dans une autre table de réplication de la même table globale.

Chaque table répliquée d'une table globale offre la même durabilité et la même disponibilité qu'une table DynamoDB à région unique. Les tables globales offrent un accord de niveau de service (SLA) de disponibilité de 99,999 %, contre 99,99 % pour les tables à région unique.

Modes de cohérence

Lorsque vous créez une table globale, vous pouvez configurer son mode de cohérence. Les tableaux globaux prennent en charge deux modes de cohérence : cohérence finale multirégionale (MREC) et cohérence forte multirégionale (MRSC).

Si vous ne spécifiez pas de mode de cohérence lors de la création d'une table globale, la table globale est définie par défaut sur la cohérence finale multirégionale (MREC). Une table globale ne peut pas contenir de répliques configurées avec différents modes de cohérence. Vous ne pouvez pas modifier le mode de cohérence d'une table globale après sa création.

Cohérence éventuelle multirégionale (MREC)

La cohérence finale multirégionale (MREC) est le mode de cohérence par défaut pour les tables globales. Les modifications d'éléments dans une réplique de table globale MREC sont répliquées de manière asynchrone sur toutes les autres répliques, généralement en une seconde ou moins. Dans le cas peu probable où une réplique d'une table globale MREC serait isolée ou altérée, toutes les données non encore répliquées dans d'autres régions seront répliquées lorsque la réplique sera saine.

Si le même élément est modifié simultanément dans plusieurs régions, DynamoDB résoudra le conflit en utilisant la modification avec le dernier horodatage interne sur une base par élément, ce que l'on appelle la méthode de résolution des conflits « le dernier écrivain gagne ». Un élément finira par converger dans toutes les répliques vers la version créée lors de la dernière écriture.

Les opérations de lecture hautement cohérentes renvoient la dernière version d'un élément si cet élément a été mis à jour pour la dernière fois dans la région où la lecture a eu lieu, mais peuvent renvoyer des données périmées si l'article a été mis à jour pour la dernière fois dans une autre région. Les écritures conditionnelles évaluent l'expression de condition par rapport à la version de l'élément dans la région.

Vous créez une table globale MREC en ajoutant une réplique à une table DynamoDB existante. L'ajout d'un réplica n'a aucun impact sur les performances des tables DynamoDB à région unique ou des répliques de tables globales existantes. Vous pouvez ajouter des répliques à une table globale MREC pour augmenter le nombre de régions dans lesquelles les données sont répliquées, ou supprimer des répliques d'une table globale MREC si elles ne sont plus nécessaires. Une table globale MREC peut comporter une réplique dans n'importe quelle région dans laquelle DynamoDB est disponible, et elle peut comporter autant de répliques que de régions dans la partition.AWS

Forte cohérence multirégionale (MRSC)

Vous pouvez configurer le mode MRSC (Multi-region Strong Cohérence) lorsque vous créez une table globale. Les modifications d'éléments dans une réplique de table globale MRSC sont répliquées de manière synchrone dans au moins une autre région avant que l'opération d'écriture ne renvoie une réponse réussie. Lorsque vous convertissez une table mono-région existante en table globale MRSC, vous devez vous assurer que la table est vide jusqu'à ce que la conversion soit terminée afin de garantir une initialisation et une configuration de réplication correctes.

Les opérations de lecture très cohérentes sur toute réplique MRSC renvoient toujours la dernière version d'un article. Les écritures conditionnelles évaluent toujours l'expression de condition par rapport à la dernière version d'un élément.

Une opération d'écriture échoue avec un ReplicatedWriteConflictException lorsqu'elle tente de modifier un élément déjà en cours de modification dans une autre région. Les écritures qui échouent ReplicatedWriteConflictException peuvent être réessayées et seront couronnées de succès si l'élément n'est plus modifié dans une autre région.

Vous pouvez configurer une table globale MRSC avec trois répliques ou avec deux répliques et un témoin. Un témoin est un composant d'une table globale MRSC qui contient des données écrites dans des répliques de tables globales et fournit une alternative facultative à une réplique complète tout en prenant en charge l'architecture de disponibilité du MRSC. Vous ne pouvez pas effectuer d'opérations de lecture ou d'écriture sur un témoin. Un témoin se trouve dans une région différente de celle des deux répliques.

Lorsque vous créez une table globale MRSC, vous choisissez les régions pour vos répliques et pour le déploiement témoin au moment de la création de la table MRSC. Vous pouvez déterminer si un témoin est configuré dans une table globale MRSC et dans quelle région à partir de la sortie de l'DescribeTableAPI. Le témoin est détenu et géré par DynamoDB, et il n'apparaîtra pas dans AWS votre compte dans la région où il est configuré.

Une table globale MRSC doit être déployée dans exactement trois régions. Vous créez une table globale MRSC en ajoutant une réplique et un témoin ou deux répliques à une table DynamoDB existante qui ne contient aucune donnée. Vous ne pouvez pas ajouter de répliques supplémentaires à une table globale MRSC existante. Vous ne pouvez pas supprimer une seule réplique ou un seul témoin d'une table globale MRSC. Vous pouvez supprimer deux répliques ou supprimer une réplique et un témoin d'une table globale MRSC, en convertissant la réplique restante en une table DynamoDB à région unique.

Les considérations suivantes s'appliquent aux tables globales du MRSC :

Choix d'un mode de cohérence

Le critère clé pour choisir un mode de cohérence multirégional est de savoir si votre application privilégie les écritures à faible latence et les lectures fortement cohérentes, ou privilégie la cohérence globale.

Les tables globales MREC auront des temps d'écriture plus faibles et des latences de lecture très cohérentes par rapport aux tables globales MRSC. Les tables globales MREC peuvent prendre en charge un objectif de point de restauration (RPO) égal au délai de réplication entre les répliques, généralement de quelques secondes selon les régions de réplication.

Vous devez utiliser le mode MREC lorsque :

Les tables globales MRSC auront des temps d'écriture plus élevés et des latences de lecture très cohérentes par rapport aux tables globales MREC. Les tables globales MRSC prennent en charge un objectif de point de récupération (RPO) de zéro.

Vous devez utiliser le mode MRSC lorsque :

Surveillance des tables globales

Les tables globales configurées pour la cohérence finale multirégionale (MREC) publient la ReplicationLatencymétrique dans. CloudWatch Cette métrique suit le temps écoulé entre le moment où un élément est écrit dans une table de réplication et le moment où cet élément apparaît dans une autre réplique de la table globale. ReplicationLatencyest exprimé en millisecondes et est émis pour chaque paire de régions source et de destination dans un tableau global.

Les ReplicationLatency valeurs typiques dépendent de la distance entre les AWS régions que vous avez choisies, ainsi que d'autres variables telles que le type de charge de travail et le débit. Par exemple, une réplique source située dans la région USA Ouest (Californie du Nord) (us-west-1) a une valeur ReplicationLatency inférieure dans la région USA Ouest (Oregon) (us-west-2) par rapport à la région Afrique (Cape Town) (af-south-1).

Une valeur croissante pour ReplicationLatency peut indiquer que les mises à jour d'une réplique ne se propagent pas aux autres tables de répliques en temps voulu. Dans ce cas, vous pouvez rediriger temporairement les activités de lecture et d'écriture de votre application vers une autre AWS région.

Les tables globales configurées pour une forte cohérence multirégionale (MRSC) ne publient aucune métrique. ReplicationLatency

Test d'injection de défauts

Les tables globales MREC s'intègrent au service d'injection de AWS défauts (AWS FIS) pour effectuer des expériences d'injection de défauts sur vos charges de travail de tables globales. Cela vous permet de tester la réponse de votre application à une simulation d'isolation de région en interrompant la réplication vers et depuis une réplique sélectionnée. Pour plus d'informations, consultez la section Suspension de la réplication globale des tables.

Durée de vie (TTL)

Les tables globales configurées pour le MREC prennent en charge la configuration de la suppression Time To Live (TTL). Les paramètres TTL sont automatiquement synchronisés pour toutes les répliques d'une table globale. Lorsque TTL supprime un élément d'une réplique dans une région, la suppression est répliquée sur toutes les autres répliques de la table globale. Le TTL ne consomme pas de capacité d'écriture. La suppression TTL ne vous est donc pas facturée dans la région où la suppression a eu lieu. Toutefois, vous êtes facturé pour la suppression répliquée dans chaque autre région avec une réplique dans le tableau global.

La réplication de suppression TTL consomme de la capacité d'écriture sur les répliques vers lesquelles la suppression est répliquée. Les répliques configurées pour la capacité allouée peuvent limiter les demandes si la combinaison du débit d'écriture et du débit de suppression TTL est supérieure à la capacité d'écriture allouée.

Les tables globales configurées pour une cohérence forte multirégionale (MRSC) ne prennent pas en charge la configuration de la suppression Time To Live (TTL).

Streams

Les tables globales configurées pour une cohérence finale multirégionale (MREC) répliquent les modifications en lisant ces modifications depuis un flux DynamoDB sur une table de réplication et en appliquant ces modifications à toutes les autres tables de réplication. Les flux sont donc activés par défaut sur toutes les répliques d'une table globale MREC et ne peuvent pas être désactivés sur ces répliques. Le processus de réplication MREC peut combiner plusieurs modifications sur une courte période en une seule écriture répliquée, ce qui fait que le flux de chaque réplique contient des enregistrements légèrement différents. Les enregistrements Streams sur les répliques MREC sont toujours classés par article, mais l'ordre entre les articles peut différer d'une réplique à l'autre.

Les tables globales configurées pour la cohérence multirégionale (MRSC) n'utilisent pas DynamoDB Streams pour la réplication. Les flux ne sont donc pas activés par défaut sur les répliques MRSC. Vous pouvez activer Streams sur une réplique MRSC. Les enregistrements Streams sur les répliques MRSC sont identiques pour chaque réplique, y compris l'ordre des enregistrements Stream.

Si vous souhaitez écrire une application qui traite les enregistrements Streams pour les modifications survenues dans une région particulière, mais pas dans d'autres régions d'une table globale, vous pouvez ajouter un attribut à chaque élément qui définit dans quelle région le changement pour cet élément s'est produit. Vous pouvez utiliser cet attribut pour filtrer les enregistrements Streams en fonction des modifications survenues dans d'autres régions, notamment en utilisant des filtres d'événements Lambda pour n'appeler les fonctions Lambda que pour les modifications dans une région spécifique.

Transactions

Sur une table globale configurée pour MREC, les opérations de transaction DynamoDB TransactWriteItems(TransactGetItemset) ne sont atomiques que dans la région où l'opération a été invoquée. Les écritures transactionnelles ne sont pas répliquées en tant qu'unité entre les régions, ce qui signifie que seules certaines des écritures d'une transaction peuvent être renvoyées par des opérations de lecture dans d'autres répliques à un moment donné.

Par exemple, si vous disposez d'une table globale contenant des répliques dans les régions USA Est (Ohio) et USA Ouest (Oregon) et que vous effectuez une TransactWriteItems opération dans la région USA Est (Ohio), vous pouvez observer des transactions partiellement achevées dans la région USA Ouest (Oregon) à mesure que les modifications sont répliquées. Les modifications ne seront répliquées dans d'autres régions qu'une fois qu'elles auront été validées dans la région source.

Les tables globales configurées pour une cohérence forte multirégionale (MRSC) ne prennent pas en charge les opérations de transaction et renvoient une erreur si ces opérations sont invoquées sur une réplique MRSC.

Débit de lecture et d'écriture

La réplication consomme de la capacité d'écriture. Les répliques configurées pour la capacité allouée peuvent limiter les demandes si la combinaison du débit d'écriture et du débit de réplication est supérieure à la capacité d'écriture allouée. La capacité d'écriture en mode à la demande est synchronisée pour toutes les répliques d'une table globale. Les tables globales configurées pour la capacité allouée synchronisent les paramètres de dimensionnement automatique entre les répliques. Le paramètre de capacité d'écriture réellement provisionnée peut varier entre les répliques en fonction du débit d'écriture consommé.

Vous pouvez configurer indépendamment les paramètres de capacité de lecture pour chaque réplique dans une table globale. Lorsque vous ajoutez une réplique à une table globale, la capacité de lecture de la table source ou de la réplique est utilisée comme valeur initiale, sauf si une valeur de remplacement est spécifiée.

Synchronisation des paramètres

Les paramètres des tables globales DynamoDB sont des paramètres de configuration qui contrôlent divers aspects du comportement des tables et de la réplication. Ces paramètres sont gérés via le APIs plan de contrôle DynamoDB et peuvent être configurés lors de la création ou de la modification de tables globales. Les tables globales synchronisent automatiquement certains paramètres entre toutes les répliques afin de maintenir la cohérence, tout en offrant une certaine flexibilité pour les optimisations spécifiques aux régions. Comprendre quels paramètres sont synchronisés et comment ils se comportent vous permet de configurer efficacement votre table globale. Les paramètres se répartissent en trois catégories principales en fonction de la façon dont ils sont synchronisés entre les répliques.

Les paramètres suivants sont toujours synchronisés entre les répliques d'une table globale :

Les paramètres suivants sont synchronisés entre les répliques, mais peuvent être remplacés au cas par cas :

Les paramètres suivants ne sont jamais synchronisés entre les répliques :

Tous les autres paramètres ne sont pas synchronisés entre les répliques.

DynamoDB Accelerator (DAX)

Les écritures sur des répliques de tables globales contournent DynamoDB Accelerator (DAX) et mettent directement DynamoDB à jour. Par conséquent, les caches DAX peuvent devenir obsolètes car les écritures ne mettent pas à jour le cache DAX. Les caches DAX configurés pour les répliques de tables globales ne seront actualisés qu'à l'expiration du TTL du cache.

Considérations relatives à la gestion des tables globales

Vous ne pouvez pas supprimer une table utilisée pour ajouter une nouvelle réplique de table globale avant que 24 heures ne se soient écoulées depuis la création de la nouvelle réplique.

Si vous désactivez une AWS région contenant des répliques de tables globales, ces répliques sont définitivement converties en tables à région unique 20 heures après la désactivation de la région.