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.
Concepts fondamentaux des tables globales
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 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 d'au moins deux répliques de tables réparties 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 plus d'informations sur la façon de démarrer avec les tables globales, consultez Tutoriels : Création de tables globales ouTutoriels : Création de tables globales multi-comptes.
Versions
Deux versions des tables globales DynamoDB sont disponibles : Tables globales version 2019.11.21 (actuelle) et Tables globales de la version 2017.11.29 (héritée). Vous devez utiliser la version 2019.11.21 (Current) de Global Tables dans la mesure du possible. Les informations contenues dans cette section de documentation concernent la version 2019.11.21 (actuelle). Pour plus d'informations, consultez la section Détermination de la version d'une table globaleDé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 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 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)
Test d’injection de pannes
Les tables globales MREC et MRSC s'intègrent au AWS Fault Injection Service (AWS FIS), un service entièrement géré permettant d'exécuter des expériences d'injection de défauts contrôlées afin d'améliorer la résilience d'une application. À l'aide du AWS FIS, vous pouvez :
-
Créez des modèles d'expérimentation qui définissent des scénarios de défaillance spécifiques.
-
Injectez les échecs pour valider la résilience des applications en simulant l'isolation des régions (c'est-à-dire en interrompant la réplication vers et depuis une réplique sélectionnée) afin de tester la gestion des erreurs, les mécanismes de restauration et le comportement de transfert du trafic multirégional lorsqu'une AWS région est perturbée.
Par exemple, dans un tableau global contenant des répliques dans l'est des États-Unis (Virginie du Nord), dans l'est des États-Unis (Ohio) et dans l'ouest des États-Unis (Oregon), vous pouvez effectuer une expérience dans l'est des États-Unis (Ohio) pour tester l'isolement de la région dans cette région tandis que l'est des États-Unis (Virginie du Nord) et l'ouest des États-Unis (Oregon) poursuivent leurs activités 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 les cibles d'action dans le guide de l'utilisateur du AWS FIS pour obtenir la liste complète des actions prises en charge par le AWS FIS et la section Connectivité entre régions pour suspendre la réplication DynamoDB entre les régions.
Pour plus d'informations sur les actions de table globales Amazon DynamoDB disponibles AWS dans FIS, consultez la référence des actions de tables globales DynamoDB dans le guide de l'utilisateur du FIS.AWS
Pour commencer à exécuter des expériences d'injection de défauts, consultez la section Planification de vos expériences AWS FIS dans le guide de l'utilisateur du AWS FIS.
Note
Au cours AWS FIS des expériences menées dans le MRSC, des lectures cohérentes sont finalement autorisées, mais les mises à jour des paramètres des tables, telles que le changement du mode de facturation ou la configuration du débit des tables, ne sont pas autorisées, comme dans le cas du MREC. Veuillez consulter la CloudWatch métrique FaultInjectionServiceInducedErrorspour plus de détails concernant le code d'erreur.
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 Streams sur les répliques MREC maintiennent l'ordre pour toutes les modifications apportées au même article, mais l'ordre relatif des modifications apportées aux différents articles peut varier d'une réplique à l'autre.
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.
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.
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é allouée peuvent limiter les demandes si la combinaison du débit d'écriture de l'application et du débit d'écriture de réplication dépasse la capacité d'écriture alloué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éplique dans une table globale en utilisant le ProvisionedThroughputOverrideparamètre au niveau de la réplique. Par défaut, les modifications apportées à la capacité de lecture allouée sont appliquées à toutes les répliques de la table globale. Lors de l'ajout d'une nouvelle 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 dérogation au niveau de la réplique est explicitement spécifiée.
Mode de capacité à la demande
Pour les tables globales configurées en mode à la demande, la capacité d'écriture est automatiquement synchronisée entre 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éplique à gérer.
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é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 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.
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 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.
