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à.
Disaster recovery e cluster globali Amazon DocumentDB
Argomenti
Utilizzando un cluster globale, puoi recuperare rapidamente da disastri come guasti regionali. Il ripristino da emergenza viene in genere misurato utilizzando i valori per RTO e RPO.
-
Obiettivo del tempo di ripristino (RTO): il tempo necessario a un sistema per tornare in uno stato funzionante dopo un'emergenza. In altre parole, l'RTO misura i tempi di inattività. Per un cluster globale, RTO in pochi minuti.
-
Obiettivo del punto di ripristino (RPO): la quantità di dati che possono essere persi (misurata nel tempo). Per un cluster globale, l'RPO viene in genere misurato in secondi.
-
Per ripristinare il sistema da un'interruzione non pianificata, è possibile eseguire un failover interregionale su uno dei sistemi secondari del cluster globale. Quando il tuo cluster globale ha più regioni secondarie, assicurati di scollegare tutte le regioni secondarie che desideri promuovere come principali. Quindi, promuovi una di quelle regioni secondarie come nuova primaria. Regione AWS Infine, crei nuovi cluster in ciascuna delle altre regioni secondarie e li colleghi al tuo cluster globale.
Esecuzione di un failover gestito per un cluster globale Amazon DocumentDB
Questo approccio è destinato alla continuità aziendale in caso di una reale emergenza a livello regionale o di un'interruzione completa del livello di servizio.
Durante un failover gestito, il cluster primario viene trasferito nella regione secondaria prescelta mentre viene mantenuta la topologia di replica esistente del cluster globale Amazon DocumentDB. Il cluster secondario scelto promuove uno dei suoi nodi di sola lettura allo stato di istanza di scrittura completa. Questo passaggio consente al cluster di assumere il ruolo di cluster primario. Il database non sarà disponibile per un breve periodo di tempo mentre il cluster sta assumendo il suo nuovo ruolo. I dati che non sono stati replicati dal vecchio cluster primario al cluster secondario scelto potrebbero mancare quando questo secondario diventa il nuovo primario. Il vecchio volume primario fa del suo meglio per scattare un'istantanea prima di sincronizzarsi con il nuovo primario, in modo da preservare i dati non replicati nell'istantanea.
Nota
È possibile eseguire un failover gestito tra più regioni su un cluster globale Amazon DocumentDB solo se il cluster primario e tutti i cluster secondari hanno le stesse versioni del motore. Se le versioni del motore non sono compatibili, puoi eseguire il failover manualmente seguendo i passaggi indicati in Esecuzione di un failover manuale per un cluster globale Amazon DocumentDB.
Se le versioni del motore della regione non corrispondono, il failover verrà bloccato. Verifica eventuali aggiornamenti in sospeso e applicali per assicurarti che tutte le versioni del motore della regione corrispondano e che il failover globale del cluster sia sbloccato. Per ulteriori informazioni, consulta Sblocco dello switchover o del failover di un cluster globale.
Per ridurre al minimo la perdita di dati, procedi come segue prima di utilizzare questa funzionalità:
Porta le applicazioni offline per evitare che le scritture vengano inviate al cluster primario del cluster globale Amazon DocumentDB.
Controlla i tempi di ritardo per tutti i cluster secondari di Amazon DocumentDB. La scelta della regione secondaria con il minor ritardo di replica può ridurre al minimo la perdita di dati relativamente all'attuale regione primaria in stato di errore. Verifica i tempi di ritardo per tutti i cluster secondari di Amazon DocumentDB nel cluster globale visualizzando la metrica in Amazon.
GlobalClusterReplicationLagCloudWatch Queste metriche mostrano il ritardo (in millisecondi) della replica su un cluster secondario rispetto al cluster primario.Per ulteriori informazioni sulle CloudWatch metriche per Amazon DocumentDB, consulta. Metriche di Amazon DocumentDB
Durante un failover gestito, il cluster secondario scelto viene promosso al nuovo ruolo di primario. Tuttavia, non eredita le varie opzioni di configurazione del cluster primario. Una mancata corrispondenza nella configurazione può causare problemi di prestazioni, incompatibilità dei carichi di lavoro e altri comportamenti anomali. Per evitare tali problemi, risolvi le differenze tra i cluster globali di Amazon DocumentDB per quanto segue:
Configura un gruppo di parametri del cluster Amazon DocumentDB per il nuovo primario, se necessario: puoi configurare i gruppi di parametri del cluster Amazon DocumentDB in modo indipendente per ogni cluster nel tuo cluster globale Amazon DocumentDB. Pertanto, quando promuovi un cluster secondario affinché assuma il ruolo principale, il gruppo di parametri del secondario potrebbe essere configurato in modo diverso rispetto a quello primario. In tal caso, modifica il gruppo di parametri del cluster secondario promosso in modo che sia conforme alle impostazioni del cluster primario. Per scoprire come, consulta Modifica dei gruppi di parametri del cluster Amazon DocumentDB.
Configura gli strumenti e le opzioni di monitoraggio, come CloudWatch gli eventi e gli allarmi di Amazon: configura il cluster promosso con la stessa capacità di registrazione, gli stessi allarmi e così via necessari per il cluster globale. Come per i gruppi di parametri, la configurazione di queste funzionalità non viene ereditata dal primario durante il processo di failover. Alcune CloudWatch metriche, come il ritardo di replica, sono disponibili solo per le regioni secondarie. Pertanto, un failover modifica il modo in cui visualizzare tali metriche e impostare i relativi allarmi e potrebbe richiedere modifiche da apportare a qualsiasi dashboard predefinito. Per ulteriori informazioni sui cluster e sul monitoraggio di Amazon DocumentDB, consulta. Monitoraggio e registrazione in Amazon DocumentDB
In genere, il cluster secondario scelto assume il ruolo principale entro un minuto. Non appena il nodo di scrittura della nuova regione primaria è disponibile, puoi connettervi le tue applicazioni e riprendere i tuoi carichi di lavoro. Dopo che Amazon DocumentDB ha promosso il nuovo cluster primario, ricostruisce automaticamente tutti i cluster regionali secondari aggiuntivi.
Poiché i cluster globali di Amazon DocumentDB utilizzano la replica asincrona, il ritardo di replica in ciascuna regione secondaria può variare. Amazon DocumentDB ricostruisce queste regioni secondarie in modo da avere esattamente gli stessi dati point-in-time del nuovo cluster di regioni primarie. La durata dell'attività di ricostruzione completa può richiedere da alcuni minuti a diverse ore, a seconda delle dimensioni del volume di archiviazione e della distanza tra regioni. Quando i cluster regionali secondari terminano la ricostruzione in base alla nuova regione primaria, diventano disponibili per l'accesso in lettura. Non appena il nuovo writer primario viene promosso e disponibile, il cluster della nuova regione primaria può gestire le operazioni di lettura e scrittura per il cluster globale Amazon DocumentDB.
Per ripristinare la topologia originale del cluster globale, Amazon DocumentDB monitora la disponibilità della vecchia regione primaria. Non appena tale regione è integra e nuovamente disponibile, Amazon DocumentDB la aggiunge automaticamente al cluster globale come regione secondaria. Prima di creare il nuovo volume di storage nella vecchia regione primaria, Amazon DocumentDB tenta di scattare un'istantanea del vecchio volume di storage nel punto in cui si è verificato l'errore. Ciò consente di usare lo snapshot per recuperare i dati mancanti. Se questa operazione ha esito positivo, Amazon DocumentDB inserisce questa istantanea denominata «rds:docdb-unplanned-global-failover-name-of-old-primary-» nella sezione snapshot del. DB-cluster-timestamp Console di gestione AWS Puoi anche vedere questa istantanea DescribeDBClusterSnapshots elencata nelle informazioni restituite dall'operazione API.
Nota
Lo snapshot del vecchio volume di archiviazione è uno snapshot del sistema soggetto al periodo di conservazione del backup configurato sul vecchio cluster primario. Per conservare questo snapshot oltre il periodo di conservazione, puoi copiarlo e salvarlo come snapshot manuale. Per ulteriori informazioni sulla copia degli snapshot, inclusi i prezzi, consulta Copiare un'istantanea del cluster.
Dopo il ripristino della topologia originale, è possibile riportare il cluster globale alla regione primaria originale eseguendo un'operazione di switchover nel momento più opportuno per l'azienda e il carico di lavoro. A tale scopo, segui la procedura in Esecuzione di uno switchover per un cluster globale Amazon DocumentDB.
Puoi eseguire il failover del tuo cluster globale Amazon DocumentDB utilizzando l'API Console di gestione AWS AWS CLI, the o Amazon DocumentDB.
Esecuzione di un failover manuale per un cluster globale Amazon DocumentDB
Se un intero cluster in uno di essi Regione AWS diventa non disponibile, puoi promuovere la funzionalità di un altro cluster nel cluster globale. read/write
È possibile attivare manualmente il meccanismo di failover globale del cluster se un cluster in un altro Regione AWS è la scelta migliore per fungere da cluster principale. Ad esempio, potrebbe essere necessario incrementare la capacità di uno dei cluster secondari e quindi promuoverlo a cluster primario. Oppure l'equilibrio delle attività tra di essi Regioni AWS potrebbe cambiare, quindi il passaggio dal cluster primario a un altro Regione AWS potrebbe comportare una latenza inferiore per le operazioni di scrittura.
La procedura seguente illustra cosa fare per promuovere uno dei cluster secondari in un cluster globale Amazon DocumentDB.
Per promuovere un cluster secondario:
-
Interrompi l'emissione di istruzioni DML e altre operazioni di scrittura sul cluster primario in caso Regione AWS di interruzione.
-
Identifica un cluster da uno secondario da Regione AWS utilizzare come nuovo cluster primario. Se ne hai due (o più) secondari Regioni AWS nel tuo cluster globale, scegli il cluster secondario con il minor tempo di ritardo.
-
Scollega il cluster secondario scelto dal cluster globale.
La rimozione di un cluster secondario da un cluster globale interrompe immediatamente la replica dal primario a questo secondario e la promuove a cluster con provisioning autonomo con funzionalità complete. read/write Qualsiasi altro cluster secondario associato al cluster primario nella regione interessata dall'interruzione è ancora disponibile e può accettare chiamate dall'applicazione. Inoltre consumano risorse. Poiché stai ricreando il cluster globale, per evitare split-brain e altri problemi, rimuovi gli altri cluster secondari prima di creare il nuovo cluster globale nei passaggi seguenti.
Per i passaggi dettagliati per lo scollegamento, consulta Rimuovere un cluster da un cluster globale Amazon DocumentDB.
-
Questo cluster diventa il cluster principale di un nuovo cluster globale quando inizi ad aggiungervi regioni, nella fase successiva.
-
Aggiungi un Regione AWS al cluster. Quando esegui questa operazione, inizia il processo di replica da primario a secondario.
-
Aggiungine altre Regioni AWS se necessario per ricreare la topologia necessaria a supportare l'applicazione. Assicurati che le scritture delle applicazioni vengano inviate al cluster corretto prima, durante e dopo aver apportato modifiche come queste, per evitare incoerenze tra i dati tra i cluster del cluster globale (problemi di split-brain).
-
Quando l'interruzione è stata risolta e sei pronto per assegnare nuovamente il cluster originale Regione AWS come cluster primario, esegui gli stessi passaggi in senso inverso.
-
Rimuovi uno dei cluster secondari dal cluster globale. Ciò gli consentirà di servire il read/write traffico.
-
Reindirizza tutto il traffico di scrittura al cluster primario dell'originale Regione AWS.
-
Aggiungi un Regione AWS per configurare uno o più cluster secondari nello stesso modo di prima Regione AWS .
I cluster globali di Amazon DocumentDB possono essere gestiti tramite AWS SDK, consentendo di creare soluzioni per automatizzare il processo di failover globale dei cluster per i casi d'uso di Disaster Recovery e Business Continuity Planning. Una di queste soluzioni è resa disponibile per i nostri clienti con licenza Apache 2.0 ed è accessibile dal nostro archivio di strumenti qui. https://github.com/awslabs/amazon-documentdb-tools/tree/master/global-clusters-automation
Esecuzione di uno switchover per un cluster globale Amazon DocumentDB
Utilizzando gli switchover, è possibile modificare regolarmente la Regione del cluster primario. Questo approccio è destinato agli scenari controllati, ad esempio durante la manutenzione operativa e altre procedure operative pianificate.
Esistono tre casi d'uso comuni per l'utilizzo degli switchover:
Per i requisiti relativi alla "rotazione regionale" imposti a settori specifici. Ad esempio, le normative sui servizi finanziari potrebbero imporre che i sistemi di livello 0 passino a un'altra regione per diversi mesi per garantire l'esecuzione regolare delle procedure di ripristino di emergenza.
Per applicazioni con approccio "follow-the-sun" in più regioni. Ad esempio, un'azienda potrebbe voler fornire scritture con latenza inferiore in diverse regioni in base all'orario di lavoro nei vari fusi orari.
Come metodo senza perdita di dati per eseguire il failback alla regione principale originale dopo un failover.
Nota
Gli switchover sono progettati per essere utilizzati su un cluster globale Amazon DocumentDB sano. Per eseguire il ripristino da un'interruzione non pianificata, puoi eseguire la procedura appropriata descritta in Esecuzione di un failover manuale per un cluster globale Amazon DocumentDB.
Per eseguire uno switchover, tutte le regioni secondarie devono eseguire esattamente la stessa versione del motore di quella principale. Se le versioni del motore della regione non corrispondono, il passaggio verrà bloccato. Verifica eventuali aggiornamenti in sospeso e applicali per assicurarti che tutte le versioni del motore della regione corrispondano e che il passaggio al cluster globale sia sbloccato. Per ulteriori informazioni, consulta Sblocco dello switchover o del failover di un cluster globale.
Durante un passaggio, Amazon DocumentDB commuta il cluster primario nella regione secondaria prescelta mantenendo la topologia di replica esistente del cluster globale. Prima di avviare il processo di passaggio, Amazon DocumentDB attende che tutti i cluster regionali secondari siano completamente sincronizzati con il cluster di regione principale. Il cluster database nella regione primaria diventa di sola lettura e il cluster secondario scelto promuove uno dei relativi nodi di sola lettura allo stato di nodo di scrittura completa. La promozione di questo nodo a nodo di scrittura consente a tale cluster secondario di assumere il ruolo di cluster primario. Poiché tutti i cluster secondari sono stati sincronizzati con il primario all'inizio del processo, il nuovo primario continua le operazioni per il cluster globale Amazon DocumentDB senza perdere alcun dato. Il database non è disponibile per un breve periodo, mentre i cluster primario e secondario selezionati assumono i loro nuovi ruoli.
Per ottimizzare la disponibilità delle applicazioni, procedi come segue prima di utilizzare questa funzionalità:
Eseguite questa operazione durante le ore non di punta o in un altro momento in cui le scritture sul cluster primario sono minime.
Porta le applicazioni offline per evitare che le scritture vengano inviate al cluster primario del cluster globale Amazon DocumentDB.
Controlla i tempi di ritardo per tutti i cluster secondari di Amazon DocumentDB nel cluster globale visualizzando la metrica in Amazon.
GlobalClusterReplicationLagCloudWatch Questa metrica mostra quanto è indietro (in millisecondi) la replica su un cluster secondario rispetto al cluster primario. Questo valore è direttamente proporzionale al tempo impiegato da Amazon DocumentDB per completare il passaggio. Di conseguenza, maggiore è il valore del ritardo, maggiore sarà il tempo necessario per lo switchover.Per ulteriori informazioni sulle CloudWatch metriche per Amazon DocumentDB, consulta. Metriche di Amazon DocumentDB
Durante uno switchover gestito, il cluster database secondario scelto viene promosso al nuovo ruolo primario. Tuttavia, non eredita le varie opzioni di configurazione del cluster di database primario. Una mancata corrispondenza nella configurazione può causare problemi di prestazioni, incompatibilità dei carichi di lavoro e altri comportamenti anomali. Per evitare tali problemi, risolvi le differenze tra i cluster globali di Amazon DocumentDB per quanto segue:
Configura il gruppo di parametri del cluster Amazon DocumentDB DB per il nuovo primario, se necessario: puoi configurare i gruppi di parametri del cluster Amazon DocumentDB in modo indipendente per ogni cluster nel tuo cluster globale Amazon DocumentDB. Ciò significa che quando si promuove un cluster di database secondario perché assuma il ruolo primario, il gruppo di parametri dal secondario potrebbe essere configurato in modo diverso rispetto al primario. In tal caso, modifica il gruppo di parametri del cluster di database secondario promosso in modo che sia conforme alle impostazioni del cluster primario. Per scoprire come, consulta Gestione dei gruppi di parametri del cluster Amazon DocumentDB.
Configura strumenti e opzioni di monitoraggio, come Amazon CloudWatch Events and alarms: configura il cluster promosso con la stessa capacità di registrazione, gli stessi allarmi e così via necessari per il cluster globale. Come per i gruppi di parametri, la configurazione di queste funzionalità non viene ereditata dal ruolo primario durante il processo di switchover. Alcune CloudWatch metriche, come il ritardo di replica, sono disponibili solo per le regioni primarie. Pertanto, uno switchover modifica il modo in cui visualizzare tali metriche e impostare i relativi allarmi e potrebbe richiedere modifiche da apportare a qualsiasi dashboard predefinito. Per ulteriori informazioni, consulta Monitoraggio e registrazione in Amazon DocumentDB.
Nota
In genere, lo switchover del ruolo può richiedere fino a diversi minuti.
Una volta completato il processo di passaggio, il cluster Amazon DocumentDB promosso può gestire le operazioni di scrittura per il cluster globale.
Puoi passare al tuo cluster globale Amazon DocumentDB utilizzando o: Console di gestione AWS AWS CLI
Sblocco dello switchover o del failover di un cluster globale
Gli switchover e i failover dei cluster globali vengono bloccati quando non tutti i cluster regionali del cluster globale utilizzano la stessa versione del motore. Se le versioni non corrispondono, potresti visualizzare questo errore quando chiami uno switchover o un failover: il cluster DB di destinazione specificato sta eseguendo una versione del motore con un livello di patch diverso rispetto al cluster DB di origine. Applica regolarmente le versioni più recenti del motore per mantenere integri i cluster globali.
Per risolvere questo errore, aggiorna prima tutte le regioni secondarie e poi la regione principale alla stessa versione del motore applicando eventuali azioni di manutenzione in sospeso. Per visualizzare le azioni di manutenzione in sospeso e applicare le modifiche necessarie per correggere il problema, segui le istruzioni in una delle seguenti schede:
