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.
Dissociation d'une réplique de table globale
Vous pouvez dissocier un réplica d'une table globale pour arrêter la réplication depuis et vers ce réplica sans supprimer sa table ou ses données. La réplique devient une table à région unique dans le même AWS compte et région et conserve son nom de table et son nom de ressource Amazon (ARN). Vous pouvez utiliser cette opération après la migration d'une région ou d'un compte, ou lorsque vous n'avez plus besoin d'une table pour participer à la réplication.
Vous pouvez dissocier les répliques des tables globales à compte unique et à comptes multiples configurées pour une cohérence éventuelle multirégionale (MREC), à l'aide de la version 2019.11.21 (actuelle) des tables globales. Cette opération n'est pas prise en charge pour la cohérence renforcée multirégionale (MRSC) ou la version 2017.11.29 (Legacy) de Global Tables.
Le résultat dépend du nombre de répliques dans la table globale :
-
Si la table globale comporte trois répliques ou plus, la réplique que vous dissociez devient une table à région unique. Les répliques restantes sont conservées sous forme de tableau global.
-
Si la table globale comporte deux répliques, les deux tables deviennent des tables à région unique. Ni le tableau ni ses données ne sont supprimés.
La table résultante conserve ses paramètres de table, notamment les index, les flux DynamoDB, la durée de vie (TTL), les sauvegardes, le chiffrement, le mode de facturation et la classe de table. Replication-specific les paramètres et les mesures ne s'appliquent plus. La table est facturée comme une table à région unique.
Rubriques
Comportement de réplication
Lorsque vous demandez la dissociation, DynamoDB établit une limite d'arrêt de réplication, un moment qu'il choisit après avoir accepté la demande, et attend que chaque réplique restante ait reçu toutes les écritures effectuées directement sur le réplica sortant jusqu'à cette limite. Si DynamoDB ne peut pas transmettre ces écritures à tous les répliques restants, la dissociation n'est pas terminée et toutes les répliques d'origine restent dans la table globale.
La table continue de servir à lire et à écrire pendant et après la dissociation. Il conserve ses données, mais comme le MREC reproduit les modifications de manière asynchrone, il se peut qu'il ne contienne pas les dernières écritures provenant d'autres régions. Lorsque la dissociation est terminée, la table n'envoie ni ne reçoit plus d'écritures répliquées.
Protection et exigences en matière de dissociation
La protection contre la dissociation est activée par défaut pour chaque réplique de table globale. Désactivez la protection contre la dissociation et attendez la fin de la mise à jour avant de demander la dissociation. La désactivation de la protection n'arrête pas la réplication. La protection contre la dissociation est indépendante de la protection contre la suppression. La désactivation de la protection contre la suppression ne désactive pas la protection contre la dissociation.
Effectuez les deux demandes depuis la région de la réplique et depuis le compte propriétaire. La réplique doit être ACTIVE, toutes les répliques doivent être accessibles, et les autorisations et l'accès par clé de chiffrement requis pour la réplication doivent rester disponibles. Une seule opération du cycle de vie des répliques peut être exécutée pour une table globale à la fois. Attendez donc que les autres opérations, notamment la création de répliques et une autre dissociation, soient terminées avant de soumettre la demande.
La dissociation est bloquée si un réplica a le statut de INACCESSIBLE_ENCRYPTION_CREDENTIALS, REPLICATION_NOT_AUTHORIZED, ARCHIVING, ou ARCHIVED. Restaurez l'accès et résolvez les problèmes de réplication avant de réessayer.
Pour une table globale multi-comptes, un compte ne peut dissocier que sa propre réplique. Vous ne pouvez pas non plus dissocier une réplique qui a servi de source à une nouvelle réplique ajoutée au cours des dernières 24 heures. Attendez que 24 heures se soient écoulées depuis l'ajout de la nouvelle réplique.
Important
Vous ne pouvez pas annuler la dissociation ni rattacher la même table à la table globale qu'elle a quittée. Avant de créer une réplique de remplacement dans cette région, appliquez les modifications que vous devez conserver de la table autonome à la table globale restante, en résolvant les différences à l'aide des règles de votre application. Supprimez ensuite la table autonome et ajoutez une nouvelle réplique. La nouvelle réplique copie les données de la table globale restante.
Autorisations requises
La dissociation utilise le Disassociate action dans le ReplicaUpdates gamme de UpdateTable. Vous avez besoin des deux dynamodb:UpdateTable et dynamodb:DisassociateTableReplica sur l'ARN de la table du réplica local. dynamodb:DisassociateTableReplica est une autorisation IAM, et non une opération d'API distincte. L'évolution de la protection contre la dissociation nécessite dynamodb:UpdateTable, et la vérification de la protection et la surveillance de l'achèvement nécessitent dynamodb:DescribeTable. La politique d'identité suivante accorde ces autorisations pour une table. Remplacez la région, l'ID de compte et le nom de la table par vos valeurs.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:UpdateTable", "dynamodb:DisassociateTableReplica", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music" } ] }
Dissocier une réplique à l'aide de AWS CLI
La procédure suivante dissocie les Music réplique en us-west-2. Utilisez les informations d'identification du compte propriétaire de cette réplique. Remplacer Music et us-west-2 avec votre table et sa région locale. Le --table-name Le paramètre accepte le nom de la table ou l'ARN de la table. Si vous utilisez un ARN, spécifiez l'ARN du réplica pour ce compte et cette région.
-
Désactivez la protection contre la dissociation sur le réplica local.
aws dynamodb update-table \ --table-nameMusic\ --regionus-west-2\ --no-disassociation-protection-enabled -
Consultez la table locale. Répétez cette commande jusqu'à ce que le tableau soit
ACTIVEetDisassociationProtectionEnabledestfalse. Ne continuez pas si le champ de protection est absent outrue.aws dynamodb describe-table \ --table-nameMusic\ --regionus-west-2\ --query 'Table.{TableStatus:TableStatus,DisassociationProtectionEnabled:DisassociationProtectionEnabled,Replicas:Replicas}' -
Soumettez une demande distincte avec un
Disassociateaction. Spécifiez la région locale et définissez explicitementDisassociationModepourWAIT_FOR_REPLICATION.aws dynamodb update-table \ --table-nameMusic\ --regionus-west-2\ --replica-updates '[{"Disassociate":{"RegionName":"us-west-2","DisassociationMode":"WAIT_FOR_REPLICATION"}}]'Une réponse réussie signifie que DynamoDB a accepté la demande. L'opération se poursuit de manière asynchrone. Un
UPDATINGl'état indique que la mise à jour est toujours en cours. -
Surveillez la table locale avec
DescribeTable.aws dynamodb describe-table \ --table-nameMusic\ --regionus-west-2\ --query 'Table.{TableStatus:TableStatus,Replicas:Replicas}'Confirmez à la fois que
TableStatusestACTIVEet çaReplicasne répertorie plus les répliques homologues. La liste peut être absente, vide ou ne contenir que la table locale. Vérifiez également l'appartenance mise à jour à partir d'une réplique restante, à l'aide des informations d'identification autorisées à décrire cette table.Important
ACTIVEà lui seul ne confirme pas le succès. Une table peut revenir àACTIVEaprès l'annulation de la dissociation et être toujours membre de la table globale. Vérifiez toujours l'adhésion Replica.
Pour plus de détails sur l'API, voir UpdateTable et DescribeTable dans le Référence de l'API Amazon DynamoDB.
Dissocier une réplique à l'aide de CloudFormation
Si un AWS::DynamoDB::GlobalTable la ressource gère la réplique, utilise son TableType propriété permettant de dissocier la réplique. CloudFormation dissocie uniquement la réplique du compte et de la région de la pile. Pour une table globale multi-comptes, chaque compte dissocie sa propre réplique de sa propre pile. Pour dissocier un réplica d'une autre région d'une table globale du même compte, importez d'abord ce réplica dans une pile de sa propre région avec TableType réglé sur GlobalTableReplica, puis exécutez les mises à jour à cet endroit. Pour plus d'informations, voir Importer AWS
ressources dans un CloudFormation empiler dans le AWS CloudFormation Guide de l'utilisateur.
La même pile continue de gérer la table une fois qu'elle est devenue régionale. Aucune table ou donnée n'est supprimée. Le directeur de l'IAM qui CloudFormation les utilisations de la mise à jour de la pile nécessitent les autorisations décrites dans Autorisations requises. Exécutez les deux mises à jour de pile suivantes dans le compte et la région de la réplique.
-
Set
DisassociationProtectionEnabledpourfalsedans leReplicasentrée pour la région de la pile, et définissezTableTypepourGlobalTableReplica. Attendez la fin de la mise à jour de la pile. La réplication se poursuit sans modification. -
Définissez
TableTypesurRegional. Ne conservez que la région de la pileReplicas, et supprimezDisassociationProtectionEnabledà partir de cette entrée. SupprimerGlobalTableSourceArnetMultiRegionConsistencys'il est présent. Si vous supprimezGlobalTableSourceArn, déclarez les paramètres que le réplica a hérités de la table source, tels queKeySchema,AttributeDefinitions,BillingMode, etStreamSpecification, avec leurs valeurs actuelles. Apportez toute autre modification de propriété lors d'une mise à jour de pile distincte. La mise à jour de la pile est terminée une fois que DynamoDB a terminé la dissociation.
Important
Le TableType le changement raconte CloudFormation pour dissocier la réplique au lieu de la supprimer. La suppression des autres entrées de région dans cette mise à jour ne supprime pas ces tables. Supprimer une entrée de réplique sans la modifier TableType pour Regional supprime cette réplique, comme dans toute autre mise à jour de pile.
Si DynamoDB rejette la dissociation ou l'annule, la table reste une réplique et la mise à jour de la pile est annulée. Résolvez le problème et relancez la deuxième mise à jour. CloudFormation
Impossible d'annuler une dissociation terminée. Si la dissociation est terminée et que la mise à jour de la pile est ensuite annulée, par exemple en raison de la défaillance d'une autre ressource, la pile entre dans le UPDATE_ROLLBACK_FAILED état. Poursuivez la restauration et ignorez la ressource du tableau. Vérifiez ensuite si la table est toujours une réplique. Si la table est désormais régionale, appliquez à nouveau la deuxième mise à jour. Pour plus d'informations, veuillez consulter la rubrique Poursuite de la restauration d'une mise à jour dans le Guide de l'utilisateur AWS CloudFormation . La restauration de la pile ne nécessite pas la suppression de la table ou de ses données. Pour éviter cet état, ne modifiez pas les autres ressources lors de la même mise à jour de pile.
Une table peut également devenir régionale en dehors de la pile. Par exemple, vous le dissociez du AWS CLI, ou un autre compte dissocie l'autre réplique d'une table globale à deux répliques. Dans les deux cas, appliquez la deuxième mise à jour. CloudFormation reconnaît que la table est déjà régionale et ne supprime pas les anciennes répliques. Courez détection de dérive ensuite pour confirmer que la pile correspond à la table.
Les exemples suivants montrent les deux mises à jour de pile pour une table globale pour un même compte et pour une table globale multi-comptes, en YAML et JSON. Les exemples utilisent des valeurs fictives : le nom de la table GT-CFN-Table et l'identifiant du compte 111122223333. Remplacez-les, ainsi que les paramètres du tableau, par vos propres valeurs. DeletionPolicy: Retain conserve la table si vous supprimez la pile ultérieurement ; cela n'est pas obligatoire pour la dissociation.
Cet exemple utilise une pile dans us-east-1 pour dissocier le us-east-1 réplique d'une table globale pour un même compte avec des répliques dans us-east-1, us-east-2, et us-west-2. Après la deuxième mise à jour, la pile gère le us-east-1 tableau en tant que tableau régional, et le us-east-2 et us-west-2 les répliques continuent sous la forme d'une table globale. La pile ne gère plus ces tables. Pour gérer le reste de la table globale avec CloudFormation, importez-le dans une pile dans us-east-2 ou us-west-2.
Mise à jour 1 : Désactiver la protection contre la dissociation
Ce modèle définit DisassociationProtectionEnabled pour false sur le us-east-1 répliques et ensembles TableType pour GlobalTableReplica. Les autres propriétés restent inchangées.
Mise à jour 2 : dissocier la réplique
Ce modèle définit TableType pour Regional, ne conserve que us-east-1 dans Replicas, et supprime DisassociationProtectionEnabled à partir de cette entrée.
Cet exemple dissocie les us-east-2 réplique d'une table globale multi-comptes. Compte A (111122223333) possède la table source dans us-east-1. Le compte B est propriétaire du us-east-2 réplique et exécute les deux mises à jour à partir de sa propre pile dans us-east-2. Comme la table globale ne comporte que deux répliques, la table du compte A devient également régionale. Le compte A peut alors définir TableType pour Regional dans son propre modèle. Cette mise à jour n'est pas requise pour que la dissociation du compte B soit terminée.
Mise à jour 1 : Désactiver la protection contre la dissociation
Ce modèle définit DisassociationProtectionEnabled pour false sur le us-east-2 répliques et ensembles TableType pour GlobalTableReplica. Les autres propriétés restent inchangées. La réplique hérite de ses paramètres de table de la table source identifiée par GlobalTableSourceArn.
Mise à jour 2 : dissocier la réplique
Ce modèle définit TableType pour Regional, supprime GlobalTableSourceArn et DisassociationProtectionEnabled, et déclare les paramètres de table hérités avec leurs valeurs actuelles.
Gestion des défaillances
Une demande rejetée lors de la validation ou de l'autorisation ne déclenche pas la dissociation. Lisez la réponse d'erreur, corrigez le problème signalé et réessayez. Par exemple, désactivez la protection contre la dissociation, attendez la fin d'une opération simultanée ou restaurez l'accès à une réplique inaccessible. Si une demande expire ou si sa réponse est perdue, vérifiez le statut et la composition de la table avant de réessayer, car la demande a peut-être été acceptée.
Une opération acceptée peut échouer ultérieurement. Par exemple, la perte de l'accès à la clé de chiffrement d'un réplica ou aux autorisations de réplication requises peut entraîner l'annulation de la dissociation. Après la restauration, la réplique fait toujours partie de la table globale. Inspectez ReplicaStatus et ReplicaStatusDescription, restaurez l'accès si nécessaire et attendez que les répliques soient actives avant de réessayer. L'inaccessibilité continue est toujours soumise au comportement de restauration existant de la table globale. Pour plus d’informations, consultez Sécurité des tables globales DynamoDB.
