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à.
Evacuazione di una regione con le tabelle globali
L'evacuazione di una regione è il processo di migrazione delle attività di lettura e scrittura da una regione specifica. Si tratta spesso di un'attività di scrittura e talvolta di un'attività di lettura.
Evacuazione di una regione in tempo reale
È possibile decidere di evacuare una regione in tempo reale per una serie di motivi. L'evacuazione potrebbe far parte di una normale attività aziendale, ad esempio se si utilizza una modalità di follow-the-sun scrittura in una regione. L'evacuazione potrebbe anche essere dovuta a una decisione aziendale di cambiare la regione attualmente attiva, in risposta a guasti nello stack software esterno a DynamoDB o a 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 già avvenute nella regione evacuata si replichino come al solito.
Con le modalità di scrittura in una regione e scrittura nella propria regione, è necessario assicurarsi che tutte le scritture nella regione attiva siano state completamente registrate, elaborate in streaming e propagate globalmente prima di iniziare le scritture nella nuova regione attiva. Ciò è necessario per garantire che le scritture future corrispondano alla 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 offline
Esiste un caso speciale da considerare: cosa succede se la Regione A risulta inaspettatamente offline? Questo scenario è altamente improbabile, ma è comunque saggio considerare anche questo tipo di evenienza. 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, è consigliabile valutare la possibilità di rieseguire il traffico di scrittura recente (ad esempio, utilizzando una fonte upstream di eventi) per colmare il divario di eventuali operazioni di scrittura potenzialmente mancanti e lasciare che la risoluzione dei conflitti relativi alla priorità dell'ultima istanza di scrittura annulli l'eventuale propagazione 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 guasto 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 Optimistic Concurrency Control (OCC) per assegnare versioni agli elementi di dati e incorporare l'ultima versione 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 OCC modello in genere 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, quando un client potrebbe incontrare 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 ultimo 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 B.
Se si verifica un guasto nella Regione C, potrebbe invece essere utilizzata una nuova Regione D. I dati nella regione C erano molto transitori e, dopo alcuni minuti, la regione D aveva una up-to-date registrazione sufficiente delle operazioni di scrittura in corso per essere pienamente utile. 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.
