View a markdown version of this page

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

Multi-account les tables globales étendent les fonctionnalités entièrement gérées, sans serveur, multirégions et multiactives des tables globales de DynamoDB pour couvrir plusieurs AWS comptes. Multi-account les tables globales répliquent les données entre AWS Régions et comptes, offrant les mêmes fonctionnalités actives-actives que les tables globales pour les mêmes comptes. Lorsque vous écrivez dans un réplica, DynamoDB réplique les données vers tous les autres réplicas.

Les principales différences par rapport aux tableaux mondiaux pour comptes comparables sont les suivantes :

  • Multi-account la réplication est prise en charge pour les tables globales de cohérence éventuelle multi-régions (MREC).

  • Vous ne pouvez ajouter des répliques qu'en commençant par une table à région unique. Pour effectuer une migration depuis une table globale pour un même compte, vous pouvez dissocier une réplique MREC. La dissociation préserve la table et ses données. La table régionale qui en résulte peut servir de source pour une nouvelle table globale multicomptes. Pour les exigences et les instructions, voir Dissociation d'une réplique de table globale.

  • Chaque réplique doit se trouver dans un endroit distinct AWS compte. Pour une table globale multi-comptes avec N des répliques, vous devez avoir N comptes.

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

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

Multi-account les tables globales utilisent la même technologie de réplication sous-jacente que les tables globales pour le même compte. Les paramètres des tables sont répliqués automatiquement sur tous les répliques régionaux, et les clients ne peuvent pas modifier ou personnaliser les paramètres par réplica. 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 les API du plan de contrôle DynamoDB lors de la création d'une table ou lors de l'ajout d'un nouveau réplica régional.

Lors de la création d'une table globale multi-comptes, les clients doivent 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 à la table globale.

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 pour un même compte, les tables globales pour plusieurs comptes ne permettent pas de modifier ces paramètres par région. La seule exception est que les remplacements pour les politiques de dimensionnement automatique en lecture (tables et GSI) 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 provisionnée dans les tables

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

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

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

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

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

  • Définition des flux en mode MREC

  • Durée de vie (TTL)

  • Débit chaud

  • On-demand débit de lecture et d'écriture maximal

Non-Synchronized Paramètres

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 de chaque région.

  • Classe de table

  • Server-side Type de cryptage (SSE)

  • Point-in-time Récupération

  • Server-side ID de clé KMS de chiffrement (SSE)

  • Protection contre la suppression

  • Protection contre la dissociation. Gérez ce paramètre dans le compte et la région du réplica. Pour plus d’informations, consultez Protection et exigences en matière de dissociation.

  • Flux de données Kinesis (KDSD)

  • Étiquettes

  • Stratégie de ressources

  • Tableau Cloudwatch-Contributor Insights (CCI)

  • GSI Cloudwatch-Contributor Insights (CCI)

Contrôle

Les tables globales configurées pour une cohérence éventuelle multirégionale (MREC) publient le ReplicationLatency métrique à 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.

Typique ReplicationLatency les valeurs dépendent de la distance entre votre choix AWS Les régions, 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 un autre AWS Région.

Gestion des problèmes de latence de réplication dans Multi-account Tableaux mondiaux

Si ReplicationLatency dépasse les 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 les clients et 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'un AWS Région hébergeant une réplique de la table globale multi-comptes

  • Refuser la table AWS Autorisations de clé KMS 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 deuxième 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 dissocie automatiquement la réplique de la table globale. La réplique concernée sera ensuite convertie en table régionale.