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à.

Best practice e requisiti per la gestione delle tabelle globali DynamoDB

Utilizzando le tabelle globali di Amazon DynamoDB, puoi replicare i dati delle tabelle tra le regioni. AWS Per garantire la corretta replica dei dati è necessario che le tabelle di replica e gli indici secondari nella tabella globale abbiano impostazioni di capacità di scrittura identiche.

Per chiarezza futura, può essere utile non inserire la regione nel nome di una qualsiasi tabella che un giorno potrebbe essere convertita in una tabella globale.

Versione per tabelle globali

Per determinare la versione della tabella globale che stai utilizzando, consultaDeterminazione della versione della tabella globale di DynamoDB in uso.

Requisiti per la gestione della capacità

Una tabella globale deve avere la capacità effettiva di trasmissione configurata in due modi:

L'utilizzo della modalità di capacità assegnata con dimensionamento automatico o della modalità di capacità on demand garantisce a una tabella globale la capacità sufficiente per eseguire scritture replicate in tutte le aree della tabella globale.

Distribuzione delle tabelle globali

In AWS CloudFormation, ogni tabella globale è controllata da un singolo stack in una singola regione. Ciò a prescindere dal numero di repliche. Quando distribuisci il modello, CloudFormation creerà/aggiornerà tutte le repliche come parte di un'unica operazione di stack. Per questo motivo, è consigliabile non distribuire la stessa risorsa AWS::DynamoDB::GlobalTable in più regioni. Questo metodo non è supportato e verranno restituiti errori.

Se distribuisci il modello di applicazione in più regioni, puoi utilizzare le condizioni per creare la risorsa in una sola regione. In alternativa, puoi scegliere di definire le risorse AWS::DynamoDB::GlobalTable in uno stack separato dallo stack di applicazioni e verificare che sia distribuito solo in una singola regione. Per ulteriori informazioni, consulta Tabelle globali in CloudFormation

Una tabella DynamoDB viene definita attraverso AWS::DynamoDB::Table e una tabella globale è AWS::DynamoDB::GlobalTable. Per quanto CloudFormation riguarda, questo li rende essenzialmente due risorse diverse. Di conseguenza, un approccio consiste nel creare tutte le tabelle che potrebbero essere globali utilizzando il costrutto GlobalTable. Per iniziare, è quindi possibile mantenerle come tabelle autonome e aggiungerle successivamente alle regioni, se necessario.

Se si dispone di una tabella normale e si desidera convertirla durante l'utilizzo CloudFormation, un metodo consigliato è il seguente:

Utilizzo di tabelle globali per semplificare la gestione di una potenziale interruzione della regione

Devi disporre o essere in grado di creare rapidamente copie indipendenti dello stack di esecuzione in regioni alternative, ognuna delle quali accede al proprio endpoint DynamoDB locale.

Usa Route53 o AWS Global Accelerator per dirigerti verso la regione sana più vicina. In alternativa, fai in modo che il client sia a conoscenza dei diversi endpoint che può utilizzare.

Utilizza i controlli dell'integrità in ciascuna regione per determinare in modo affidabile se ci sono problemi con lo stack, incluso se DynamoDB è danneggiato. Ad esempio, non limitarti ad eseguire il ping dell'endpoint DynamoDB per verificare se è attivo. Esegui effettivamente una chiamata che assicuri il completamento di un flusso di database.

Se il controllo di integrità fallisce, il traffico può essere indirizzato verso altre regioni (aggiornando la DNS voce con Route53, impostando Global Accelerator un percorso diverso o facendo scegliere al client un endpoint diverso). Le tabelle globali hanno un buon obiettivo RPO (obiettivo del punto di ripristino) perché i dati si sincronizzano continuamente e un buono RTO (obiettivo del tempo di ripristino) perché entrambe le regioni mantengono sempre una tabella pronta per il traffico di lettura e scrittura.

Per ulteriori informazioni sui controlli dell'integrità, consultare Tipi di controllo dell'integrità.

Backup delle tabelle globali

Quando si esegue il backup delle tabelle globali, dovrebbe essere sufficiente un backup delle tabelle in una regione e non dovrebbe essere necessario il backup di tutte le tabelle in tutte le regioni. Se lo scopo è quello di poter recuperare dati cancellati o modificati erroneamente, dovrebbe essere sufficiente utilizzare un'unica PITR regione. Analogamente, quando si mantiene uno snapshot per scopi di cronologia come i requisiti normativi, il backup in una regione dovrebbe essere sufficiente. I dati di backup possono essere replicati in più regioni tramite AWS Backup.

Repliche e calcolo delle unità di scrittura

Per la pianificazione, dovresti utilizzare il numero di scritture che verrà eseguito da una regione e aggiungerlo al numero di scritture che avvengono per ogni altra regione. Questo è fondamentale in quanto ogni scrittura eseguita in una regione deve essere eseguita anche in ogni regione di replica. Se non si dispone di capacità sufficiente per gestire tutte le scritture, si verificano eccezioni di capacità. Inoltre, i tempi di attesa per la replica interregionale aumenteranno.

Si supponga, ad esempio, di prevedere 5 scritture al secondo nella tabella di replica in Ohio, 10 scritture al secondo nella tabella di replica in Virginia settentrionale e 5 scritture al secondo nella tabella di replica in Irlanda. In questo caso, dovresti aspettarti di consumarne 20 rWCUs o rWRUs in ogni regione: Ohio, Virginia settentrionale e Irlanda. In altre parole, dovresti aspettarti di consumarne 60 in rWCUs totale in tutte e tre le regioni.

Per informazioni dettagliate sulla capacità assegnata con dimensionamento automatico e DynamoDB, vedi Gestione automatica della capacità effettiva di trasmissione con il dimensionamento automatico di DynamoDB.