Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Dissociazione di una replica globale della tabella
È possibile dissociare una replica da una tabella globale per interrompere la replica da e verso tale replica senza eliminarne la tabella o i dati. La replica diventa una tabella a regione singola nella stessa AWS account e regione e mantiene il nome della tabella e Amazon Resource Name (ARN). Puoi utilizzare questa operazione dopo una migrazione di una regione o di un account o quando non hai più bisogno di una tabella per partecipare alla replica.
È possibile dissociare le repliche dalle tabelle globali con lo stesso account e con più account configurate per la coerenza finale multiregionale (MREC), utilizzando la versione 2019.11.21 (attuale) di Global Tables. Questa operazione non è supportata per Multi-region Strong Consistency (MRSC) o Global Tables versione 2017.11.29 (Legacy).
Il risultato dipende dal numero di repliche nella tabella globale:
-
Se la tabella globale contiene tre o più repliche, la replica dissociata diventa una tabella a regione singola. Le repliche rimanenti continuano come tabella globale.
-
Se la tabella globale contiene due repliche, entrambe le tabelle diventano tabelle a regione singola. Né la tabella né i relativi dati vengono eliminati.
La tabella risultante mantiene le impostazioni della tabella, inclusi indici, DynamoDB Streams, Time to Live (TTL), backup, crittografia, modalità di fatturazione e classe di tabella. Replication-specific le impostazioni e le metriche non si applicano più. La tabella viene fatturata come tabella a regione singola.
Argomenti
Comportamento di replica
Quando si richiede la dissociazione, DynamoDB stabilisce un limite di interruzione della replica, un momento che sceglie dopo aver accettato la richiesta e attende che ogni replica rimanente abbia ricevuto tutte le scritture effettuate direttamente sulla replica in partenza fino a quel limite. Se DynamoDB non è in grado di fornire tali scritture a tutte le repliche rimanenti, la dissociazione non viene completata e tutte le repliche originali rimangono nella tabella globale.
La tabella continua a fornire letture e scritture durante e dopo la dissociazione. Mantiene i dati, ma poiché MREC replica le modifiche in modo asincrono, potrebbe non contenere le ultime scritture provenienti da altre regioni. Una volta completata la dissociazione, la tabella non invia o riceve più scritture replicate.
Protezione e requisiti relativi alla dissociazione
La protezione da disassociazione è abilitata per impostazione predefinita per ogni replica globale della tabella. Disabilita la protezione da dissociazione e attendi il completamento dell'aggiornamento prima di richiedere la dissociazione. La disabilitazione della protezione non interrompe la replica. La protezione da disassociazione è indipendente dalla protezione da eliminazione. La disattivazione della protezione da eliminazione non disabilita la protezione da dissociazione.
Effettua entrambe le richieste dalla regione e dall'account proprietario della replica. La replica deve essere ACTIVE, tutte le repliche devono essere raggiungibili e le autorizzazioni e l'accesso con chiave di crittografia necessari per la replica devono rimanere disponibili. È possibile eseguire una sola operazione del ciclo di vita della replica per una tabella globale, quindi attendi il completamento delle altre operazioni, tra cui la creazione della replica e un'altra dissociazione, prima di inviare la richiesta.
La disassociazione viene bloccata se una replica ha lo stato di INACCESSIBLE_ENCRYPTION_CREDENTIALS, REPLICATION_NOT_AUTHORIZED, ARCHIVING, o ARCHIVED. Ripristina l'accesso e risolvi i problemi di replica prima di riprovare.
Per una tabella globale con più account, un account può dissociare solo la propria replica. Inoltre, non è possibile dissociare una replica che è stata utilizzata come origine per una nuova replica aggiunta nelle ultime 24 ore. Attendi che siano trascorse 24 ore dall'aggiunta della nuova replica.
Importante
Non è possibile annullare la dissociazione o ricollegare la stessa tabella alla tabella globale lasciata. Prima di creare una replica sostitutiva in quella regione, applica le modifiche necessarie dalla tabella autonoma alla tabella globale rimanente, risolvendo le differenze utilizzando le regole dell'applicazione. Quindi elimina la tabella autonoma e aggiungi una nuova replica. La nuova replica copia i dati dalla tabella globale rimanente.
Autorizzazioni richieste
La disassociazione utilizza Disassociate azione nel ReplicaUpdates serie di UpdateTable. Ti servono entrambi dynamodb:UpdateTable e dynamodb:DisassociateTableReplica sulla tabella ARN della replica locale. dynamodb:DisassociateTableReplica è un'autorizzazione IAM, non un'operazione API separata. La modifica della protezione da dissociazione richiede dynamodb:UpdateTablee il controllo del completamento della protezione e del monitoraggio richiedono dynamodb:DescribeTable. La seguente politica di identità concede queste autorizzazioni per una tabella. Sostituisci la regione, l'ID dell'account e il nome della tabella con i tuoi valori.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:UpdateTable", "dynamodb:DisassociateTableReplica", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music" } ] }
Dissociazione di una replica utilizzando AWS CLI
La procedura seguente dissocia Music replica in us-west-2. Usa le credenziali per l'account che possiede questa replica. Sostituisci Music e us-west-2 con il tuo tavolo e la sua Regione locale. Il --table-name il parametro accetta il nome della tabella o l'ARN della tabella. Se si utilizza un ARN, specificare l'ARN della replica in quell'account e nella regione.
-
Disabilita la protezione da dissociazione sulla replica locale.
aws dynamodb update-table \ --table-nameMusic\ --regionus-west-2\ --no-disassociation-protection-enabled -
Controllate la tabella locale. Ripetere questo comando finché la tabella non è
ACTIVEeDisassociationProtectionEnabledèfalse. Non procedere se il campo di protezione è assente otrue.aws dynamodb describe-table \ --table-nameMusic\ --regionus-west-2\ --query 'Table.{TableStatus:TableStatus,DisassociationProtectionEnabled:DisassociationProtectionEnabled,Replicas:Replicas}' -
Invia una richiesta separata con una
Disassociateazione. Specifica la regione locale e impostala in modo esplicitoDisassociationModeaWAIT_FOR_REPLICATION.aws dynamodb update-table \ --table-nameMusic\ --regionus-west-2\ --replica-updates '[{"Disassociate":{"RegionName":"us-west-2","DisassociationMode":"WAIT_FOR_REPLICATION"}}]'Una risposta positiva significa che DynamoDB ha accettato la richiesta. L'operazione continua in modo asincrono. Un
UPDATINGlo stato indica che l'aggiornamento è ancora in corso. -
Monitora la tabella locale con
DescribeTable.aws dynamodb describe-table \ --table-nameMusic\ --regionus-west-2\ --query 'Table.{TableStatus:TableStatus,Replicas:Replicas}'Conferma entrambi
TableStatusèACTIVEe quelloReplicasnon elenca più alcuna replica peer. L'elenco può essere assente, vuoto o contenere solo la tabella locale. Verifica inoltre l'appartenenza aggiornata di una replica rimanente, utilizzando le credenziali autorizzate per descrivere quella tabella.Importante
ACTIVEda solo non conferma il successo. Una tabella potrebbe tornare aACTIVEdopo la dissociazione torna indietro ed è comunque un membro della tabella globale. Controlla sempre l'appartenenza alla replica.
Per informazioni dettagliate sull'API, consulta UpdateTable e DescribeTable nel Riferimento all'API Amazon DynamoDB.
Dissociazione di una replica utilizzando CloudFormation
Se un AWS::DynamoDB::GlobalTable la risorsa gestisce la replica, usa la sua TableType proprietà per dissociare la replica. CloudFormation dissocia solo la replica nell'account e nella regione dello stack. Per una tabella globale con più account, ogni account dissocia la propria replica dal proprio stack. Per dissociare una replica in un'altra regione di una tabella globale dello stesso account, importa innanzitutto tale replica in uno stack nella propria regione con TableType impostato su GlobalTableReplica, quindi esegui gli aggiornamenti lì. Per ulteriori informazioni, vedere Importa AWS
risorse in un CloudFormation pila nel AWS CloudFormation Guida per l'utente.
Lo stesso stack continua a gestire la tabella dopo che è diventata regionale. Nessuna tabella o dato viene eliminato. Il preside IAM che CloudFormation gli usi per l'aggiornamento dello stack necessitano delle autorizzazioni descritte in Autorizzazioni richieste. Esegui entrambi i seguenti aggiornamenti dello stack nell'account e nella regione della replica.
-
Imposta
DisassociationProtectionEnabledafalsenelReplicasvoce per la regione dello stack e impostataTableTypeaGlobalTableReplica. Attendi il completamento dell'aggiornamento dello stack. La replica continua invariata. -
Imposta
TableTypesuRegional. Mantieni solo la regione dello stack inReplicase rimuoviDisassociationProtectionEnabledda quella voce. RimuoviGlobalTableSourceArneMultiRegionConsistencyse presente. Se rimuoviGlobalTableSourceArn, dichiara le impostazioni che la replica ha ereditato dalla tabella di origine, ad esempioKeySchema,AttributeDefinitions,BillingMode, eStreamSpecification, con i loro valori correnti. Apporta qualsiasi altra modifica alla proprietà in un aggiornamento separato dello stack. L'aggiornamento dello stack viene completato dopo che DynamoDB ha terminato la dissociazione.
Importante
Il TableType il cambiamento racconta CloudFormation per dissociare la replica anziché eliminarla. La rimozione delle altre voci relative alla regione in questo aggiornamento non comporta l'eliminazione di tali tabelle. Rimuovere una voce di replica senza modificarla TableType a Regional elimina quella replica, come in qualsiasi altro aggiornamento dello stack.
Se DynamoDB rifiuta la dissociazione o la ripristina, la tabella rimane una replica e l'aggiornamento dello stack viene ripristinato. Risolvi la causa ed esegui nuovamente il secondo aggiornamento. CloudFormation
non è possibile annullare una dissociazione completata. Se la dissociazione viene completata e l'aggiornamento dello stack viene ripristinato, ad esempio perché un'altra risorsa non funziona, lo stack entra nel UPDATE_ROLLBACK_FAILED stato. Continua il rollback e salta la risorsa della tabella. Quindi controlla se la tabella è ancora una replica. Se la tabella è ora regionale, applica nuovamente il secondo aggiornamento. Per ulteriori informazioni, consulta Rollback di un aggiornamento nella Guida per l'utente di AWS CloudFormation . Il ripristino dello stack non richiede l'eliminazione della tabella o dei relativi dati. Per evitare questo stato, non modificate altre risorse nello stesso aggiornamento dello stack.
Una tabella può anche diventare regionale all'esterno dello stack. Ad esempio, la si dissocia dal AWS CLI, oppure un altro account dissocia l'altra replica di una tabella globale con due repliche. In entrambi i casi, applica il secondo aggiornamento. CloudFormation riconosce che la tabella è già regionale e non elimina le repliche precedenti. Esegui rilevamento della deriva successivamente per confermare che la pila corrisponde alla tabella.
Gli esempi seguenti mostrano i due aggiornamenti dello stack per una tabella globale con lo stesso account e per una tabella globale con più account, in YAML e JSON. Gli esempi utilizzano valori fittizi: il nome della tabella GT-CFN-Table e l'ID dell'account 111122223333. Sostituiscili, insieme alle impostazioni della tabella, con i tuoi valori. DeletionPolicy: Retain mantiene la tabella se successivamente si elimina lo stack; non è necessario per la dissociazione.
Questo esempio utilizza uno stack in us-east-1 per dissociare il us-east-1 replica di una tabella globale dello stesso account con repliche in us-east-1, us-east-2, e us-west-2. Dopo il secondo aggiornamento, lo stack gestisce il us-east-1 tabella come tabella regionale e us-east-2 e us-west-2 le repliche continuano a essere una tabella globale. Lo stack non gestisce più tali tabelle. Per gestire la tabella globale rimanente con CloudFormation, importalo in una pila in us-east-2 o us-west-2.
Aggiornamento 1: disabilita la protezione da dissociazione
Questo modello imposta DisassociationProtectionEnabled a false sul us-east-1 replica e set TableType a GlobalTableReplica. Le altre proprietà sono invariate.
Aggiornamento 2: dissociare la replica
Questo modello imposta TableType a Regional, conserva solo us-east-1 nel Replicase rimuove DisassociationProtectionEnabled da quella voce.
Questo esempio dissocia il us-east-2 replica di una tabella globale con più account. Conto A (111122223333) possiede la tabella di origine in us-east-1. L'account B possiede il us-east-2 replica ed esegue entrambi gli aggiornamenti dal proprio stack in us-east-2. Poiché la tabella globale ha solo due repliche, anche la tabella dell'Account A diventa regionale. L'account A può quindi impostare TableType a Regional nel proprio modello. Questo aggiornamento non è necessario per il completamento della dissociazione dell'Account B.
Aggiornamento 1: disabilita la protezione dalla dissociazione
Questo modello imposta DisassociationProtectionEnabled a false sul us-east-2 replica e set TableType a GlobalTableReplica. Le altre proprietà sono invariate. La replica eredita le impostazioni della tabella dalla tabella di origine identificata da GlobalTableSourceArn.
Aggiornamento 2: dissociare la replica
Questo modello imposta TableType a Regional, rimuove GlobalTableSourceArn e DisassociationProtectionEnablede dichiara le impostazioni della tabella ereditate con i valori correnti.
Gestione degli errori
Una richiesta rifiutata durante la convalida o l'autorizzazione non avvia la dissociazione. Leggi la risposta all'errore, correggi il problema segnalato e riprova. Ad esempio, disabilitate la protezione da dissociazione, attendete il completamento di un'operazione simultanea o ripristinate l'accesso a una replica inaccessibile. Se una richiesta scade o la sua risposta viene persa, controlla lo stato e l'appartenenza della tabella prima di riprovare perché la richiesta potrebbe essere stata accettata.
Un'operazione accettata può fallire in seguito. Ad esempio, la perdita dell'accesso alla chiave di crittografia di una replica o alle autorizzazioni di replica richieste può causare il rollback della dissociazione. Dopo il rollback, la replica rimane parte della tabella globale. Ispeziona ReplicaStatus e ReplicaStatusDescription, ripristina l'accesso dove necessario e attendi che le repliche diventino attive prima di riprovare. L'inaccessibilità continua è ancora soggetta al comportamento di ripristino esistente della tabella globale. Per ulteriori informazioni, consulta Sicurezza per tabelle globali DynamoDB.