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à. # Elenco di controllo di preparazione per tabelle globali DynamoDB Utilizza il seguente elenco di controllo per decisioni e attività relative all’implementazione delle tabelle globali. + Determina se il caso d’uso trae maggiori vantaggi da una modalità di coerenza MRSC o MREC. È necessaria un’elevata consistenza, anche con una latenza più elevata e altri compromessi? + Determina quante e quali Regioni devono essere incluse nella tabella globale. Se intendi utilizzare MRSC, decidi se desideri che la terza Regione sia una replica o un testimone. + Determina la modalità di scrittura dell’applicazione. Questa non è la stessa della modalità di coerenza. Per ulteriori informazioni, consulta [Modalità di scrittura con le tabelle globali DynamoDB](bp-global-table-design.prescriptive-guidance.writemodes.md). + Pianifica la strategia [Strategie di instradamento in DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) in base alla modalità di scrittura scelta. + Definisci i [ Processi di evacuazione Evacuazione di una regione con le tabelle globali L’evacuazione di una Regione è il processo di migrazione delle attività, solitamente delle attività di lettura e scrittura, o delle attività di lettura, dalla Regione. Evacuazione di una regione in tempo realeRegioni in tempo reale Evacuazione di una regione in tempo reale Potresti decidere di evacuare una regione attiva per diversi motivi: come parte della normale attività aziendale (ad esempio, se utilizzi una modalità di scrittura in una regione) follow-the-sun, a causa della decisione aziendale di modificare la regione attualmente attiva, in risposta a guasti nello stack software esterno a DynamoDB o perché stai riscontrando problemi generali come latenze più elevate del solito all'interno della regione. Con la modalità di *scrittura in qualsiasi regione*, l'evacuazione di una regione in tempo reale è semplice. È possibile instradare il traffico verso le Regioni alternative tramite qualsiasi sistema di instradamento e lasciare che le operazioni di scrittura della Regione evacuata si replichino come al solito. Le modalità di scrittura in una Regione e quella di scrittura nella propria Regione vengono generalmente utilizzate con le tabelle MREC. Pertanto, è necessario assicurarsi che tutte le operazioni di scrittura nella nuova Regione attiva siano state completamente registrate, elaborate in streaming e propagate globalmente prima di iniziare le operazioni di scrittura nella nuova Regione attiva, per garantire che le future operazioni di scrittura vengano elaborate sulla versione più recente dei dati. Si supponga che la regione A sia attiva e la regione B sia passiva (per la tabella completa o per gli elementi che si trovano nella regione A). Il meccanismo tipico per eseguire un'evacuazione consiste nel sospendere le operazioni di scrittura nella Regione A, attendere il tempo necessario affinché tali operazioni si siano propagate completamente nella Regione B, aggiornare lo stack dell'architettura per riconoscere la Regione B come attiva e quindi riprendere le operazioni di scrittura nella Regione B. Non esiste una metrica che indichi con assoluta certezza che la Regione A ha replicato completamente i propri dati nella Regione B. Se la Regione A è integra, la sospensione delle operazioni di scrittura nella regione A e l'attesa di 10 volte il valore massimo recente della metrica `ReplicationLatency` sarebbero in genere sufficienti per determinare che la replica è completa. Se la Regione A non è integra e mostra altre aree con latenze aumentate, per definire il tempo di attesa scegliere un valore multiplo più grande. Evacuazione di una regione offlineRegioni offline Evacuazione di una regione offline Esiste un caso speciale da considerare: cosa succede se la Regione A risulta inaspettatamente offline? Ciò è estremamente improbabile, ma va comunque considerato. Evacuazione di una tabella MRSC offline Se ciò accade con una tabella MRSC, non è necessario fare nulla di particolare. Le tabelle MRSC supportano un obiettivo del punto di ripristino (RPO) pari a zero. Tutte le operazioni di scrittura eseguite correttamente sulla tabella MRSC nella Regione offline saranno disponibili in tutte le altre tabelle delle Regioni, quindi non vi è alcuna potenziale lacuna nei dati anche se la Regione passa completamente offline senza preavviso. Le aziende possono continuare a utilizzare le repliche situate nelle altre Regioni. Evacuazione di una tabella MREC offline In questo caso, tutte le operazioni di scrittura nella Regione A non ancora propagate vengono conservate e propagate dopo che la Regione A torna online. Le operazioni di scrittura non vengono perse, ma la loro propagazione viene ritardata a tempo indeterminato. Come procedere in questo caso dipende dall'applicazione. Per la continuità aziendale, potrebbe essere necessario procedere alle operazioni di scrittura nella nuova Regione B. Tuttavia, se un elemento nella Regione B riceve un aggiornamento mentre è in corso la propagazione di un'operazione di scrittura per tale elemento dalla Regione A, la propagazione viene soppressa in base al modello basato sulla *priorità dell'ultima istanza di scrittura*. Qualsiasi aggiornamento nella Regione B potrebbe eliminare una richiesta di scrittura in arrivo. Con la modalità di *scrittura in qualsiasi Regione*, le operazioni di lettura e scrittura possono continuare nella Regione B, con la certezza che gli elementi nella Regione A alla fine si propagheranno alla Regione B e con la possibilità di elementi mancanti fino a quando la Regione A non tornerà online. Quando possibile, come con le operazioni di scrittura idempotenti, è consigliabile valutare la possibilità di rieseguire il traffico di scrittura recente (ad esempio, utilizzando una fonte a monte di eventi) per colmare la lacuna di eventuali operazioni di scrittura potenzialmente mancanti e lasciare che la risoluzione dei conflitti relativi alla priorità dell’ultima istanza di scrittura annulli la propagazione finale dell’operazione di scrittura in entrata. Con le altre modalità di scrittura, è necessario considerare il grado in cui il lavoro può continuare con una out-of-date visione leggermente del mondo. Alcune operazioni di scrittura di breve durata, tracciate da `ReplicationLatency`, risulteranno mancanti fino a quando la Regione A non tornerà online. L'attività aziendale può andare avanti? In alcuni casi d'uso ciò è possibile, ma in altri casi potrebbe non essere possibile senza meccanismi di mitigazione aggiuntivi. Ad esempio, si supponga di dover mantenere disponibile il saldo del credito senza interruzioni anche dopo un’interruzione totale nella Regione. È possibile dividere il saldo in due elementi diversi, uno situato nella Regione A e uno nella Regione B, ciascuno riferito a metà del saldo disponibile. In questo caso si utilizzerebbe la modalità di *scrittura nella propria regione*. Gli aggiornamenti transazionali elaborati in ciascuna regione verrebbero contabilizzati sulla copia locale del saldo. Se la Regione A passa alla modalità offline, l'elaborazione delle transazioni nella Regione B potrebbe continuare e le operazioni di scrittura sarebbero limitate alla parte del saldo conservata nella Regione B. Suddividere il saldo in questo modo comporta difficoltà quando il saldo si esaurisce o il credito deve essere ribilanciato, ma fornisce un esempio di ripristino aziendale sicuro anche con operazioni di scrittura in sospeso incerte. Per fare un altro esempio, si supponga di acquisire i dati dei moduli web. È possibile utilizzare la funzionalità di [controllo della simultaneità ottimistica](DynamoDBMapper.OptimisticLocking.md) (OCC, Optimistic Concurrency Control) per assegnare versioni agli elementi di dati e incorporare la versione più recente nel modulo web come campo nascosto. Ad ogni invio, l'operazione di scrittura ha esito positivo solo se la versione nel database corrisponde alla versione con cui è stato creato il modulo. Se le versioni non corrispondono, il modulo web può essere aggiornato (o unito) in base alla versione corrente nel database e l'utente può procedere. Il modello OCC di solito protegge dalla sovrascrittura e dalla produzione di una nuova versione dei dati da parte di un altro client, ma può anche essere utile durante il failover, situazione in cui un client potrebbe riscontrare versioni precedenti dei dati. Si supponga di utilizzare il timestamp come versione. Si immagini inoltre che il modulo sia stato creato per la prima volta nella Regione A alle 12:00 ma (dopo il failover) tenti di eseguire un’operazione di scrittura nella Regione B e si accorga che l’ultima versione nel database risale alle 11:59. In questo scenario, il client può attendere che la versione delle 12:00 si propaghi nella Regione B e quindi sovrascrivere su quella versione oppure eseguire una compilazione alle 11:59 e creare una nuova versione alle 12:01 (che, dopo la scrittura, eliminerebbe la versione in arrivo dopo il ripristino della Regione A). Come terzo esempio, una società di servizi finanziari conserva i dati sugli account dei clienti e sulle relative transazioni finanziarie in un database DynamoDB. In caso di interruzione completa dei servizi nella Regione A, la società vuole essere sicura che qualsiasi attività di scrittura relativa ai propri account sia disponibile nella Regione B oppure che i propri account vengano messi in quarantena come account parzialmente noti fino a quando la Regione A non torna online. Invece di sospendere tutte le attività, la società decide di sospendere l'attività solo per la piccola parte di account con transazioni ritenute non propagate. A tal fine, la società utilizza una terza regione, definita Regione C. Prima di elaborare qualsiasi operazione di scrittura nella Regione A, nella Regione C la società inserisce un breve riepilogo delle operazioni in sospeso (ad esempio, un nuovo numero di transazioni per un conto). Questo riepilogo è sufficiente per consentire alla Regione B di determinare se la visualizzazione è completamente aggiornata. Questa azione effettivamente blocca l'account dal momento della scrittura nella Regione C fino a quando la Regione A accetta le operazioni di scrittura e la Regione B le riceve. I dati nella Regione C non vengono utilizzati se non come parte di un processo di failover, dopodiché la Regione B controlla i dati con quelli della Regione C per verificare se alcuni dei suoi account non sono aggiornati. Tali account vengono contrassegnati come messi in quarantena fino a quando il ripristino della Regione A non propaga i dati parziali alla Regione C, potrebbe invece essere utilizzata una nuova Regione D. I dati nella regione C erano molto transitori e dopo pochi minuti la regione D avrebbe avuto una up-to-date registrazione sufficiente delle operazioni di scrittura in volo per essere pienamente utili. Se si verifica un guasto nella Regione B, la Regione A potrebbe continuare ad accettare richieste di scrittura in collaborazione con la Regione C. La società è disposta ad accettare scritture a latenza più elevata (verso due regioni, ovvero C e poi A) ed è fortunata a disporre di un modello di dati in cui lo stato di un account può essere riassunto in modo sintetico. ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title) [Processi di evacuazione](bp-global-table-design.prescriptive-guidance.evacuation.md) in base alla modalità di coerenza, alla modalità di scrittura e alla strategia di instradamento scelti. + Acquisisci metriche su integrità, latenza ed errori in ogni Regione. Per un elenco dei parametri di DynamoDB, consulta AWS il post del blog Monitoring [Amazon DynamoDB for Operational Awareness per](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) un elenco di metriche da osservare. È inoltre consigliabile utilizzare [canary sintetici](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (richieste artificiali progettate per rilevare i guasti), nonché l'osservazione in tempo reale del traffico dei clienti. Non tutti i problemi verranno visualizzati nelle metriche di DynamoDB. + In caso di utilizzo di MREC, imposta allarmi per qualsiasi aumento prolungato di `ReplicationLatency`. Un incremento potrebbe indicare una configurazione errata accidentale in cui la tabella globale ha impostazioni di scrittura diverse in varie regioni, il che porta a richieste replicate non riuscite e a un aumento della latenza. Potrebbe anche indicare che si è verificata un'interruzione dei servizi a livello regionale. Un [buon esempio](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) è generare un avviso se il valore medio recente supera i 180.000 millisecondi. È anche possibile controllare se `ReplicationLatency` scende a 0; ciò indica una replica bloccata. + Assegna impostazioni massime di lettura e scrittura sufficienti per ogni tabella globale. + Individuare in anticipo i motivi dell'evacuazione di una regione. Se la decisione implica un giudizio umano, documentare tutte le considerazioni. Questa fase deve essere svolta con attenzione in anticipo, non in situazioni di stress. + Gestire un runbook per ogni operazione da eseguire in caso di evacuazione di una regione. Di solito è richiesto pochissimo lavoro per le tabelle globali, ma il trasferimento del resto dello stack potrebbe essere una procedura complessa. **Nota** Con le procedure di failover, è consigliabile fare affidamento solo sulle operazioni del piano dati e non sulle operazioni del piano di controllo (control-plane) perché alcune operazioni del piano di controllo (control-plane) potrebbero degradarsi durante i guasti a livello di Regione. Per ulteriori informazioni, consulta il post AWS sul blog [Crea applicazioni resilienti con le tabelle globali di Amazon DynamoDB](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/): parte 4. + Testa periodicamente tutti gli aspetti del runbook, comprese le evacuazioni della Regione. Un runbook non testato è un runbook inaffidabile. + Considera la possibilità di utilizzare [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) per valutare la resilienza dell’intera applicazione (comprese le tabelle globali). Fornisce una visione completa dello stato di resilienza complessivo del portafoglio di applicazioni tramite il relativo pannello di controllo. + Considera la possibilità di utilizzare i controlli di idoneità del sistema ARC per valutare la configurazione corrente dell’applicazione e tenere traccia di eventuali anomalie rispetto alle best practice. + In caso di scrittura di controlli di integrità da utilizzare con Route 53 o Global Accelerator, esegui una serie di chiamate che coprano l’intero flusso del database. Se limiti il controllo alla sola conferma che l'endpoint DynamoDB è attivo, non sarai in grado di coprire molte modalità di errore AWS Identity and Access Management come errori di configurazione (IAM), problemi di distribuzione del codice, errori nello stack esterno a DynamoDB, latenze di lettura o scrittura superiori alla media e così via. ## Domande frequenti relative alla distribuzione delle tabelle globali **Quali sono i prezzi delle tabelle globali?** + Il prezzo di un'operazione di scrittura in una tabella DynamoDB tradizionale è espresso in unità di capacità di scrittura WCUs (per le tabelle fornite) o in unità di richiesta di scrittura () per le WRUs tabelle su richiesta. In caso di scrittura di un elemento da 5 KB, viene addebitato un costo pari a 5 unità. Il prezzo di un'operazione di scrittura su una tabella globale è espresso in unità di capacità di scrittura replicate (rWCUs, per le tabelle fornite) o in unità di richiesta di scrittura replicate (rWRUs, per le tabelle su richiesta). r e r hanno lo stesso prezzo di and. WCUs WRUs WGUs WRUs + I costi di rWCU e rWRU vengono applicati in tutte le Regioni in cui l’elemento viene scritto direttamente o tramite una replica. Si applicano tariffe per il trasferimento di dati tra regioni. + La scrittura su un indice secondario globale (GSI) è considerata una scrittura locale e utilizza le normali unità di scrittura. + Al momento non è disponibile alcuna capacità riservata per r o r. WCUs WRUs L'acquisto di capacità riservata per WCUs può essere utile per le tabelle in cui si GSIs consumano unità di scrittura. + Quando aggiungi una nuova Regione a una tabella globale, DynamoDB avvia automaticamente la nuova Regione e ti addebita come se si trattasse di un ripristino della tabella, in base alla sua dimensione in GB. Addebita inoltre tariffe aggiuntive per il trasferimento di dati tra regioni. **Quali sono regioni supportate dalle tabelle globali?** [La versione 2019.11.21 (corrente) di Global Tables](GlobalTables.md) supporta tutte le tabelle MREC e i seguenti set di regioni Regioni AWS per le tabelle MRSC: + Set della Regione degli Stati Uniti: Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (Oregon) + Set della Regione Europa: Europa (Irlanda), Europa (Londra), Europa (Parigi), Europa (Francoforte) + Set della Regione Asia Pacifico: Asia Pacifico (Tokyo), Asia Pacifico (Seoul) e Asia Pacifico (Osaka) **Come vengono gestite le tabelle globali? GSIs ** Nelle [Tabelle globali versione 2019.11.21 (Corrente)](GlobalTables.md), quando viene creato un GSI in una Regione, tale indice viene automaticamente creato e compilato nelle altre Regioni partecipanti. **Come posso interrompere la replica di una tabella globale?** + È possibile eliminare una tabella di replica con la stessa procedura usata per eliminare qualsiasi altra tabella. Ciò interromperà la replica ed eliminerà la copia della tabella conservata in tale regione. Tuttavia, non è possibile interrompere la replica e conservare le copie della tabella come entità indipendenti, né è possibile sospendere la replica. + Una tabella MRSC deve essere distribuita esattamente in tre Regioni. Per eliminare le repliche è necessario eliminare tutte le repliche e il testimone in modo che la tabella MRSC diventi una tabella locale. **In che modo i flussi DynamoDB interagiscono con le tabelle globali?** + Ogni tabella globale produce un flusso indipendente basato su tutte le relative operazioni di scrittura, a prescindere dal punto di partenza. È possibile scegliere di utilizzare il flusso DynamoDB in una regione o in tutte le regioni in modo indipendente. Per elaborare operazioni di scrittura locali non replicate, è possibile aggiungere l’attributo relativo alla regione a ciascun elemento. È quindi possibile utilizzare un filtro di eventi Lambda per richiamare solo la funzione Lambda per le operazioni di scrittura nella regione locale. Questa procedura serve per le operazioni di inserimento e aggiornamento, ma non per le operazioni di eliminazione. + Le tabelle globali configurate per la coerenza finale tra più Regioni (tabelle MREC) replicano le modifiche leggendo tali modifiche da un flusso DynamoDB su una tabella di replica e applicandole a tutte le altre tabelle di replica. Pertanto, DynamoDB è abilitato per impostazione predefinita su tutte le repliche in una tabella globale MREC e non può essere disabilitato su tali repliche. Il processo di replica MREC può combinare più modifiche in un breve periodo di tempo in un’unica operazione di scrittura replicata. Di conseguenza, il flusso di ogni replica potrebbe contenere record leggermente diversi. I record dei flussi DynamoDB sulle repliche MREC vengono sempre ordinati per elemento, ma l’ordinamento tra gli elementi potrebbe differire tra le repliche. + Le tabelle globali configurate per un’elevata consistenza multi-Regione (tabelle MRSC) non utilizzano i flussi DynamoDB per la replica, quindi questa funzionalità non è abilitata per impostazione predefinita sulle repliche MRSC. È possibile abilitare i flussi DynamoDB su una replica MRSC. I record dei flussi DynamoDB sulle repliche MRSC sono identici per ogni replica e vengono sempre ordinati per elemento, ma l’ordinamento tra gli elementi potrebbe differire tra le repliche. **In che modo le tabelle globali gestiscono le transazioni?** + Le operazioni transazionali sulle tabelle MRSC genereranno errori. + Le operazioni transazionali sulle tabelle MREC forniscono garanzie di atomicità, consistenza, isolamento e durabilità (ACID) solo all’interno della Regione in cui si è originariamente verificata l’operazione di scrittura. Le transazioni non sono supportate tra le regioni nelle tabelle globali. Ad esempio, se è presente una tabella globale MREC con repliche nelle Regioni Stati Uniti orientali (Ohio) e Stati Uniti occidentali (Oregon) e si esegue un’operazione `TransactWriteItems` nella Regione Stati Uniti orientali (Ohio), è possibile osservare transazioni parzialmente completate nella Regione Stati Uniti occidentali (Oregon) man mano che le modifiche vengono replicate. Le modifiche vengono replicate in altre Regioni solo dopo essere state confermate nella Regione di origine. **In che modo le tabelle globali interagiscono con la cache DynamoDB Accelerator (DAX)?** Le tabelle globali ignorano DAX aggiornando direttamente DynamoDB, quindi DAX non è consapevole della presenza di dati obsoleti. La cache DAX verrà aggiornata solo alla scadenza del TTL della cache. **I tag presenti nelle tabelle vengono propagati?** No, i tag non vengono propagati automaticamente. **Devo eseguire il backup delle tabelle in tutte le regioni o solo in una?** La risposta dipende dallo scopo del backup. + Se è necessario garantire la durabilità dei dati, DynamoDB fornisce già questa protezione. Il servizio garantisce la durabilità dei dati. + Se si desidera conservare uno snapshot dei record storici (ad esempio per soddisfare i requisiti normativi), il backup in una regione dovrebbe essere sufficiente. È possibile copiare il backup in altre regioni utilizzando AWS Backup. + Se desideri recuperare dati cancellati o modificati erroneamente, utilizza [DynamoDB point-in-time recovery](PointInTimeRecovery_Howitworks.md) (PITR) in una regione. **Come posso distribuire tabelle globali utilizzando? CloudFormation** + CloudFormation rappresenta una tabella DynamoDB e una tabella globale come due risorse separate: e. `AWS::DynamoDB::Table` `AWS::DynamoDB::GlobalTable` Un approccio consiste nel creare tutte le tabelle che possono essere potenzialmente globali utilizzando il costrutto `GlobalTable` per mantenerle inizialmente come tabelle autonome e aggiungere Regioni in un secondo momento, se necessario. + In CloudFormation, ogni tabella globale è controllata da un singolo stack, in una singola regione, indipendentemente dal numero di repliche. Quando distribuisci il modello, CloudFormation crea e aggiorna tutte le repliche come parte di un'unica operazione di stack. Non è consigliabile distribuire la stessa risorsa [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) in più regioni. Questo metodo non è supportato e genererà errori. Se si distribuisce il modello di applicazione in più regioni, è possibile utilizzare le condizioni per creare la risorsa `AWS::DynamoDB::GlobalTable` solo in una regione. In alternativa, è possibile scegliere di definire le risorse `AWS::DynamoDB::GlobalTable` in uno stack separato dallo stack dell'applicazione e verificare che sia distribuito solo in un'unica regione. + Se disponi di una tabella normale e desideri convertirla in una tabella globale mantenendola gestita, imposta la politica di eliminazione su`Retain`, rimuovi la tabella dallo stack, converti la tabella in una tabella globale nella console e quindi importa la tabella globale come nuova risorsa nello stack. CloudFormation [Per ulteriori informazioni, consulta il AWS GitHub repository.](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk) + La replica su più account non è al momento supportata.