Processi di evacuazione

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.

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 valutare fino a che punto il processo può continuare con una visione del mondo leggermente obsoleta. 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 (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 sono molto transitori e dopo pochi minuti la Regione D è caratterizzata da record delle operazioni di scrittura in corso sufficientemente aggiornati da poter essere considerati 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.