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 reproduit les données des tables entre les régions. AWS

Une table de réplica (ou réplica) est une table DynamoDB unique qui fonctionne comme une partie d’une table globale. Une table globale se compose de deux tables de répliques ou plus dans différentes AWS régions. Une table globale donnée ne peut avoir qu’une seule table de réplica par région AWS . 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.

Quand une application écrit des données dans une réplique d’une région, DynamoDB réplique automatiquement l’écriture aux autres réplicas dans la table globale. Pour en savoir plus sur la mise en route avec 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 (héritée). 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étermination de 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 AWS région est altérée, vous pouvez déplacer le trafic des applications vers une autre région et effectuer des lectures et des écritures dans une autre table de répliques dans la même table globale.

Chaque table de réplica 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 contrat de niveau de service (SLA) avec une 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 tables globales prennent en charge deux modes de cohérence : la cohérence à terme multirégionale (MREC) et la forte cohérence 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 à terme multirégionale (MREC). Une table globale ne peut pas contenir de réplicas configurés 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.

Multi-Region cohérence éventuelle (MREC)

Multi-Region la cohérence éventuelle (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 « victoire du dernier auteur ». 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 fortement 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éplicas de tables globales existantes. Vous pouvez ajouter des réplicas à une table globale MREC pour augmenter le nombre de régions dans lesquelles les données sont répliquées, ou supprimer des réplicas d’une table globale MREC si elles ne sont plus nécessaires. Une table globale MREC peut comporter un réplica dans n’importe quelle région dans laquelle DynamoDB est disponible, et elle peut comporter autant de réplicas que de régions dans la partition AWS.

Multi-Region forte cohérence (MRSC)

Vous pouvez configurer le mode MRSC (forte cohérence multirégionale) lorsque vous créez une table globale. Les modifications d’éléments dans un réplica 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. Les opérations de lecture fortement cohérente sur tout réplica MRSC renvoient toujours la dernière version d’un élément. Les écritures conditionnelles évaluent toujours l’expression de condition par rapport à la dernière version d’un élément.

Une table globale MRSC doit être déployée dans exactement trois régions. Vous pouvez configurer une table globale MRSC avec trois réplicas, ou avec deux réplicas 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éplicas. 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 et dans quelle région une table globale MRSC comporte un témoin configuré à partir de la sortie de l’API DescribeTable. Le témoin est détenu et géré par DynamoDB, et il n'apparaîtra pas dans votre AWS compte dans la région où il est configuré.

Les tableaux mondiaux MRSC sont disponibles dans les ensembles de régions suivants : ensemble de régions des États-Unis (États-Unis est de la Virginie du Nord, États-Unis de l'est de l'Ohio, États-Unis de l'ouest de l'Oregon), ensemble de régions de l'UE (Europe Irlande, Europe Londres, Europe Paris, Europe Europe, Europe Francfort) et ensemble de régions AP (Asie-Pacifique Tokyo, Asie-Pacifique Séoul et Asie-Pacifique Osaka). Les tables globales MRSC ne peuvent pas couvrir des ensembles régionaux (par exemple, une table globale MRSC ne peut pas contenir de réplicas d’ensembles régionaux des États-Unis et de l’UE).

Vous créez une table globale MRSC en ajoutant un réplica et un témoin, ou deux réplicas à une table DynamoDB existante qui ne contient aucune donnée. Lorsque vous convertissez une table à région unique existante en une table globale MRSC, vous devez vous assurer que la table est vide. La conversion d’une table à région unique en une table globale MRSC contenant des éléments existants n’est pas prise en charge. Assurez-vous qu’aucune donnée n’est écrite dans la table pendant le processus de conversion. Vous ne pouvez pas ajouter de réplicas supplémentaires à une table globale MRSC existante. Vous ne pouvez pas supprimer un seul réplica ou un seul témoin d’une table globale MRSC. Vous pouvez supprimer deux réplicas ou supprimer un réplica et un témoin d’une table globale MRSC, en convertissant le réplica restant en une table DynamoDB à région unique.

Une opération d’écriture échoue avec une 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 réussiront si l'élément n'est plus modifié dans une autre région.

Les considérations suivantes s’appliquent aux tables globales 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 fortement cohérentes par rapport aux tables globales MRSC. Les tables globales MREC ont 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épliques.

Vous devez utiliser le mode MREC lorsque :

Les tables globales MRSC auront des temps d’écriture plus élevés et des latences de lecture fortement cohérentes par rapport aux tables globales MREC. Les tables MRSC prennent en charge un objectif de point de reprise (RPO) de zéro.

Vous devez utiliser le mode MREC lorsque :

Surveillance des tables globales

Les tables globales configurées pour une cohérence éventuelle multirégionale (MREC) publient la ReplicationLatency métrique dans. CloudWatch Cette métrique suit le temps écoulé entre le moment où un élément est écrit dans une table de réplicas et celui où il apparaît dans un autre réplica dans la table globale. ReplicationLatency est exprimé en millisecondes et est émis pour chaque paire région source/région de destination dans une table globale.

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, un réplica source située dans la région USA Ouest (Californie du Nord) (us-west-1) a une ReplicationLatency inférieure dans la région USA Ouest (Oregon) (us-west-2) par rapport à la région Afrique (Le Cap) (af-south-1).

Une valeur croissante pour ReplicationLatency peut indiquer que les mises à jour d’un réplica ne sont pas propagées vers d’autres tables de réplica dans un délai raisonnable. Dans ce cas, vous pouvez rediriger temporairement l'activité 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 pannes

Les tables globales MREC et MRSC s'intègrent à AWS Fault Injection Service (AWS FIS), un service entièrement géré permettant de réaliser des expériences d'injection de défauts contrôlées afin d'améliorer la résilience d'une application. Grâce à AWS FIS, vous pouvez :

Par exemple, dans un tableau global contenant des répliques dans l'est des États-Unis (Virginie du Nord), l'est des États-Unis (Ohio) et l'ouest des États-Unis (Oregon), vous pouvez exécuter une expérience dans l'est (Ohio) pour tester l'isolement de la région pendant que les États-Unis de l'Est (Virginie du Nord) et de l'Ouest (Oregon) poursuivent leurs opérations normales. Ces tests contrôlés vous aident à identifier et à résoudre les problèmes potentiels avant qu’ils n’affectent les charges de travail de production.

Consultez la section Cibles d'action dans le guide de l'utilisateur de la AWS FIS pour obtenir la liste complète des actions prises en charge par la AWS FIS et la Cross-Region connectivité permettant de suspendre la réplication DynamoDB entre les régions.

Pour plus d'informations sur les actions de table globale Amazon DynamoDB disponibles dans AWS FIS, consultez la référence des actions de tables globales DynamoDB dans le guide de l'AWS utilisateur FIS.

Pour commencer à réaliser des expériences d'injection par défaut, consultez la section Planification de vos expériences AWS FIS dans le guide de l'utilisateur de la AWS FIS.

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 tous les réplicas d’une table globale. Lorsque la TTL supprime un élément d’un réplica dans une région, la suppression est répliquée sur tous les autres réplicas de la table globale. La TTL n’utilise 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 un réplica dans la table globale.

La réplication de suppression TTL utilise de la capacité d’écriture sur les réplicas dans lesquels la suppression est répliquée. Les réplicas configurés 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 forte cohérence multirégionale (MRSC) ne prennent pas en charge la configuration de la suppression Time To Live (TTL).

Flux

Les tables globales configurées pour une cohérence à terme entre plusieurs régions (MREC) répliquent les modifications en lisant ces modifications à partir de flux DynamoDB sur une table de réplica et en appliquant cette modification à toutes les autres tables de réplica. Les flux sont donc activés par défaut sur tous les réplicas d’une table globale MREC et ne peuvent pas être désactivé sur ces réplicas. 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éplica contient des enregistrements légèrement différents. Les enregistrements de flux sur les réplicas MREC sont toujours classés par article, mais l’ordre entre les éléments peut différer selon les réplicas.

Les tables globales configurées pour une forte cohérence multirégionale (tables MRSC) n’utilisent pas les flux DynamoDB pour la réplication. Cette fonctionnalité n’est donc pas activée par défaut sur les réplicas MRSC. Vous pouvez activer les flux sur un réplica MRSC. Les enregistrements de flux sur les répliques MRSC sont identiques pour chaque réplica, y compris l’ordre des enregistrements de flux.

Si vous souhaitez écrire une application qui traite les enregistrements de flux 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 de flux 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 et TransactGetItems) 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éplicas à un instant dans le passé donné.

Par exemple, si vous avez une table globale avec des réplicas dans les régions USA Est (Ohio) et USA Ouest (Oregon), et que vous réalisez une opération TransactWriteItems dans la région USA Est (Ohio), vous remarquerez peut-être des transactions partiellement incomplètes dans la région USA Ouest (Oregon) lorsque les changements sont répliqués. Les changements seront uniquement répliqués aux autres régions une fois validés dans la région source.

Les tables globales configurées pour une forte cohérence 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

Mode alloué

La réplication consomme de la capacité d’écriture. Les répliques configurées pour la capacité provisionnée peuvent limiter les demandes si la combinaison du débit d'écriture de l'application et du débit d'écriture de la réplication dépasse la capacité d'écriture provisionnée. Pour les tables globales utilisant le mode provisionné, les paramètres de dimensionnement automatique pour les capacités de lecture et d'écriture sont synchronisés entre les répliques.

Vous pouvez configurer indépendamment les paramètres de capacité de lecture pour chaque réplica dans une table globale en utilisant le ProvisionedThroughputOverride paramètre au niveau du réplica. Par défaut, les modifications apportées à la capacité de lecture provisionnée sont appliquées à toutes les répliques de la table globale. Lors de l'ajout d'un nouveau réplica à une table globale, la capacité de lecture de la table source ou du réplica est utilisée comme valeur initiale, sauf si un remplacement au niveau de la réplication est explicitement spécifié.

On-demand mode

Pour les tables globales configurées pour le mode à la demande, la capacité d'écriture est automatiquement synchronisée sur toutes les répliques. DynamoDB ajuste automatiquement la capacité en fonction du trafic, et il n'existe aucun paramètre de capacité de lecture ou d'écriture spécifique à la réplication à gérer.

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 les API du 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 tous les réplicas 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éplicas.

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

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

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

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

DynamoDB Accelerator (DAX)

Les écritures dans des réplicas 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éplicas de tables globales ne seront actualisés que lorsque la TTL du cache expirera.

Considérations relatives à la gestion des tables globales

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

Si vous désactivez une AWS région qui contient 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.