Fonctionnement des tables globales DynamoDB - Amazon DynamoDB
Contrôle

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 tables globales multicomptes étendent les fonctionnalités multirégionales et multiactives des tables globales DynamoDB entièrement gérées, sans serveur, à plusieurs régions et à plusieurs comptes. AWS Les tables globales multi-comptes répliquent les données entre AWS les régions et les comptes, fournissant les mêmes fonctionnalités active-active que les tables globales pour les mêmes comptes. Lorsque vous écrivez sur une réplique, DynamoDB réplique les données sur toutes les autres répliques.

Les principales différences par rapport aux tables globales pour comptes identiques sont les suivantes :

  • La réplication multicompte est prise en charge pour les tables globales de cohérence éventuelle multirégionale (MREC).

  • Vous ne pouvez ajouter des répliques qu'en commençant par une table à région unique. La conversion d'une table globale existante pour un même compte en une configuration multi-comptes n'est pas prise en charge. Pour effectuer la migration, vous devez supprimer les répliques existantes pour revenir à une table à région unique avant de créer une nouvelle table globale multi-comptes.

  • Chaque réplique doit résider dans un AWS compte distinct. Pour une table globale multi-comptes comportant N répliques, vous devez disposer de N comptes.

  • Les tables globales multicomptes utilisent par défaut des paramètres de table unifiés pour toutes les répliques. Toutes les répliques partagent automatiquement la même configuration (comme le mode débit, TTL et PITR) et, contrairement aux tables globales de même compte, ces paramètres ne peuvent pas être remplacés par réplique.

  • Les clients doivent fournir des autorisations de réplication au principal du service de tables globales DynamoDB dans leurs politiques de ressources.

Les tables globales à comptes multiples utilisent la même technologie de réplication sous-jacente que les tables globales à compte identique. Les paramètres de table sont répliqués automatiquement sur toutes les répliques régionales, et les clients ne peuvent pas modifier ou personnaliser les paramètres par réplique. Cela garantit une configuration cohérente et un comportement prévisible sur plusieurs AWS comptes participant à la même table globale.

Les paramètres des tables globales DynamoDB définissent le comportement d'une table et la manière dont les données sont répliquées entre les régions. Ces paramètres sont configurés via le APIs plan de contrôle DynamoDB lors de la création de la table ou lors de l'ajout d'une nouvelle réplique régionale.

Lors de la création d'un tableau global multi-comptes, les clients doivent le définir GlobalTableSettingsReplicationMode = ENABLED pour chaque réplique régionale. Cela garantit que les modifications de configuration apportées dans une région se propagent automatiquement à toutes les autres régions qui participent au tableau global.

Vous pouvez activer la réplication des paramètres après la création de la table. Cela prend en charge le scénario dans lequel une table est initialement créée en tant que table régionale puis mise à niveau vers une table globale multi-comptes.

Réglages synchronisés

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

Note

Contrairement aux tables globales à comptes identiques, les tables globales à comptes multiples n'autorisent pas le remplacement de ces paramètres par région. La seule exception est que les remplacements pour les politiques d'auto-scaling en lecture (tables GSIs et) sont autorisés car il s'agit de ressources externes distinctes.

  • Mode capacité (capacité provisionnée ou à la demande)

  • Capacité de lecture et d'écriture allouée aux tables

  • Mise à l'échelle automatique en lecture et en écriture de tableaux

  • Définition de l'index secondaire local (LSI)

  • Définition de l’index secondaire global (GSI)

  • Capacité de lecture et d'écriture allouée par GSI

  • Mise à l'échelle automatique de lecture et d'écriture GSI

  • Définition des flux en mode MREC

  • Durée de vie (TTL)

  • Débit chaud

  • Débit de lecture et d'écriture maximal à la demande

Réglages non synchronisés

Les paramètres suivants ne sont pas synchronisés entre les répliques et doivent être configurés indépendamment pour chaque table de répliques dans chaque région.

  • Classe de table

  • Type de chiffrement côté serveur (SSE)

  • ID de clé KMS de chiffrement côté serveur (SSE)

  • Protection contre la suppression

  • Kinesis Data Streams (KDSD)

  • Étiquettes

  • Stratégie de ressources

  • Tableau Cloudwatch-Contributor Insights (CCI)

  • Informations sur les contributeurs de GSI Cloudwatch (CCI)

Contrôle

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.

Gestion des problèmes de latence de réplication dans les tables globales multi-comptes

Si ReplicationLatency le délai dépasse 3 heures en raison de problèmes provoqués par le client sur une table de réplication, DynamoDB envoie une notification demandant au client de résoudre le problème sous-jacent. Les problèmes courants provoqués par le client susceptibles d'empêcher la réplication sont notamment les suivants :

  • Suppression des autorisations requises de la politique de ressources de la table de réplication

  • Se désinscrire d'une AWS région hébergeant une réplique de la table globale multi-comptes

  • Refuser les autorisations relatives AWS à la clé KMS de la table requises pour déchiffrer les données

DynamoDB envoie une notification initiale dans les 3 heures suivant une latence de réplication élevée, suivie d'une seconde notification après 20 heures si le problème n'est toujours pas résolu. Si le problème n'est pas résolu dans le délai imparti, DynamoDB dissociera automatiquement le réplica de la table globale. La réplique affectée sera ensuite convertie en table régionale.