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à.
Implementa il disaster recovery tra regioni con Amazon AWS DMS Aurora
Creato da Mark Hudson () AWS
Ambiente: produzione | Tecnologie: database | AWSservizi: AWSDMS; AmazonRDS; Amazon Aurora |
Riepilogo
I disastri naturali o causati dall'uomo possono verificarsi in qualsiasi momento e possono influire sulla disponibilità di servizi e carichi di lavoro in esecuzione in una determinata regione di Amazon Web Services (). AWS Per mitigare i rischi, è necessario sviluppare un piano di disaster recovery (DR) che incorpori le funzionalità integrate dei servizi interregionali. AWS Per AWS i servizi che non forniscono intrinsecamente funzionalità interregionali, il piano DR deve fornire anche una soluzione per gestire il failover tra le regioni. AWS
Questo modello ti guida attraverso una configurazione di disaster recovery che coinvolge due cluster di database Amazon Aurora My SQL -Compatible Edition in un'unica regione. Per soddisfare i requisiti di DR, i cluster di database sono configurati per utilizzare la funzionalità di database globale di Amazon Aurora, con un singolo database che si estende AWS su più regioni. Un task AWS Database Migration Service (AWSDMS) replica i dati tra i cluster nella regione locale. AWSDMS, tuttavia, attualmente non supporta il failover delle attività tra regioni. Questo modello include i passaggi necessari per aggirare tale limitazione e configurare in modo indipendente AWS DMS in entrambe le regioni.
Prerequisiti e limitazioni
Prerequisiti
AWSRegioni primarie e secondarie selezionate che supportano i database globali di Amazon Aurora.
Due cluster di database Amazon Aurora My SQL -Compatible Edition indipendenti in un unico account nella regione principale.
Classe di istanza di database db.r5 o superiore (consigliata).
Un'AWSDMSattività nella regione principale che esegue la replica continua tra i cluster di database esistenti.
Risorse della regione DR disponibili per soddisfare i requisiti per la creazione di istanze di database. Per ulteriori informazioni, consulta Lavorare con un'istanza DB in a VPC.
Limitazioni
Per l'elenco completo delle limitazioni dei database globali di Amazon Aurora, consulta Limitazioni dei database globali di Amazon Aurora.
Versioni del prodotto
Amazon Aurora My SQL - Edizione compatibile con Amazon Aurora My 5.7 o 8.0. Per ulteriori informazioni, consulta le versioni di Amazon Aurora.
Architettura
Stack tecnologico Target
Cluster di database globale Amazon Aurora My SQL -Compatible Edition
AWS DMS
Architettura Target
Il diagramma seguente mostra un database globale per due AWS regioni, una con i database principali e reporter e la AWS DMS replica, e una con i database principali e reporter secondari.
Automazione e scalabilità
È possibile utilizzare AWS CloudFormation per creare l'infrastruttura prerequisita nella regione secondaria, ad esempio il cloud privato virtuale (VPC), le sottoreti e i gruppi di parametri. È inoltre possibile utilizzare AWS CloudFormation per creare i cluster secondari nella regione DR e aggiungerli al database globale. Se sono stati utilizzati CloudFormation modelli per creare i cluster di database nella regione primaria, è possibile aggiornarli o ampliarli con un modello aggiuntivo per creare la risorsa di database globale. Per ulteriori informazioni, consulta Creazione di un cluster Amazon Aurora DB con due istanze DB e Creazione di un cluster di database globale per Aurora My. SQL
Infine, puoi creare le AWS DMS attività nelle regioni primarie e secondarie utilizzando CloudFormation dopo che si sono verificati eventi di failover e failback. Per ulteriori informazioni, vedere AWS::DMS:
Strumenti
Amazon Aurora - Amazon Aurora è un motore di database relazionale completamente gestito compatibile con My e Postgre. SQL SQL Questo modello utilizza Amazon Aurora My SQL -Compatible Edition.
Database globali Amazon Aurora - I database globali di Amazon Aurora sono progettati per applicazioni distribuite a livello globale. Un singolo database globale di Amazon Aurora può estendersi su più regioni. AWS Replica i dati senza alcun impatto sulle prestazioni del database. Consente inoltre letture locali veloci con bassa latenza in ogni regione e fornisce il disaster recovery in caso di interruzioni a livello regionale.
AWSDMS- AWS Database Migration Service (AWSDMS) fornisce una migrazione una tantum o una replica continua. Un'attività di replica continua mantiene sincronizzati i database di origine e di destinazione. Dopo la configurazione, l'attività di replica in corso applica continuamente le modifiche all'origine alla destinazione con una latenza minima. Tutte le AWS DMS funzionalità, come la convalida e la trasformazione dei dati, sono disponibili per qualsiasi attività di replica.
Epiche
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Modifica il gruppo di parametri del cluster di database. | Nel gruppo di parametri del cluster di database esistente, attiva la registrazione binaria a livello di riga impostando il AWSDMSrichiede la registrazione binaria a livello di riga per i database MYSQL compatibili quando si esegue la replica continua o si modifica l'acquisizione dei dati (). CDC Per ulteriori informazioni, vedere Utilizzo di un database AWS gestito SQL compatibile con My come origine per. AWS DMS | AWSamministratore |
Aggiorna il periodo di conservazione dei log binari del database. | Utilizzando un SQL client My installato sul dispositivo dell'utente finale o un'istanza Amazon Elastic Compute Cloud (AmazonEC2), esegui la seguente procedura memorizzata fornita da Amazon Relational Database Service (RDSAmazon) sul nodo writer del cluster di database principale,
Conferma l'impostazione eseguendo il comando seguente.
I miei database SQL compatibili gestiti da AWS eliminano i log binari il prima possibile. Pertanto, il periodo di conservazione deve essere sufficientemente lungo da garantire che i log non vengano eliminati prima dell'esecuzione dell'attività. AWS DMS Un valore di 24 ore è in genere sufficiente, ma il valore deve basarsi sul tempo necessario per impostare l'AWSDMSattività nella regione DR. | DBA |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Registra l'AWSDMSattivitàARN. | Usa Amazon Resource Name (ARN) per ottenere il nome dell'AWSDMSattività da utilizzare in un secondo momento. Per recuperare l'AWSDMSattivitàARN, visualizza l'attività nella console o esegui il comando seguente.
An ARN ha il seguente aspetto.
I caratteri dopo l'ultimo punto corrispondono al nome dell'attività utilizzato in un passaggio successivo. | AWSamministratore |
Modifica l'AWSDMSattività esistente per registrare il checkpoint. | AWSDMScrea checkpoint che contengono informazioni in modo che il motore di replica conosca il punto di ripristino per il flusso di modifiche. Per registrare le informazioni sui checkpoint, effettuate le seguenti operazioni nella console:
| AWSamministratore |
Convalida le informazioni sul checkpoint. | Utilizzando un SQL client My connesso all'endpoint writer per il cluster, interroga la nuova tabella di metadati nel cluster di database reporter per verificare che esista e contenga le informazioni sullo stato della replica. Esegui il comando seguente.
Il nome dell'attività di ARN deve essere trovato in questa tabella nella colonna. | DBA |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Crea un'infrastruttura di base nella regione DR. | Crea i componenti di base necessari per la creazione e l'accesso ai cluster Amazon Aurora:
Assicuratevi che la configurazione di entrambi i gruppi di parametri corrisponda alla configurazione nella regione principale. | AWSamministratore |
Aggiungi la regione DR a entrambi i cluster Amazon Aurora. | Aggiungi una regione secondaria (la regione DR) ai cluster Amazon Aurora principali e reporter. Per ulteriori informazioni, consulta Aggiungere una AWS regione a un database globale Amazon Aurora. | AWSamministratore |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Interrompi l'AWSDMSoperazione. | L'AWSDMSattività nella regione principale non funzionerà correttamente dopo il failover e deve essere interrotta per evitare errori. | AWSamministratore |
Eseguire un failover gestito. | Eseguire un failover gestito del cluster di database principale nella regione DR. Per istruzioni, consulta Esecuzione di failover pianificati gestiti per i database globali di Amazon Aurora. Una volta completato il failover sul cluster di database principale, esegui la stessa attività sul cluster di database reporter. | AWSamministratore, DBA |
Carica i dati nel database principale. | Inserisci i dati di test nel nodo writer del database principale nel cluster di database DR. Questi dati verranno utilizzati per verificare che la replica funzioni correttamente. | DBA |
Crea l'istanza di AWS DMS replica. | Per creare l'istanza di AWS DMS replica nella regione DR, vedere Creazione di un'istanza di replica. | AWSamministratore, DBA |
Crea gli endpoint AWS DMS di origine e di destinazione. | Per creare gli endpoint di AWS DMS origine e di destinazione nella regione DR, vedere Creazione degli endpoint di origine e di destinazione. L'origine deve puntare all'istanza writer del cluster di database principale. La destinazione deve puntare all'istanza writer del cluster di database reporter. | AWSamministratore, DBA |
Ottenere il checkpoint di replica. | Per ottenere il checkpoint di replica, utilizzate un SQL client My per interrogare la tabella dei metadati eseguendo quanto segue sul nodo writer nel cluster di database reporter nella regione DR.
Nella tabella, trova il valore task_name che corrisponde all'AWSDMSattività esistente nella regione primaria ARN che hai ottenuto nella seconda epic. | DBA |
Crea un'attività. AWS DMS | Utilizzando la console, crea un'AWSDMSattività nella regione DR. Nell'attività, specifica un metodo di migrazione di Replica solo le modifiche dei dati. Per ulteriori informazioni, vedere Creazione di un'attività.
Imposta l'impostazione dell'AWSDMSattività Avvia l'attività di migrazione su Automaticamente alla creazione. | AWSamministratore, DBA |
Registra l'AWSDMSoperazioneARN. | Utilizzare il ARN per ottenere il nome dell'AWSDMSattività per un uso successivo. Per recuperare l'AWSDMSattivitàARN, esegui il comando seguente.
| AWSamministratore, DBA |
Convalida i dati replicati. | Interroga il cluster di database reporter nella regione DR per confermare che i dati di test caricati nel cluster di database principale siano stati replicati. | DBA |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Interrompi l'AWSDMSoperazione. | L'AWSDMSattività nella regione DR non funzionerà correttamente dopo il failback e deve essere interrotta per evitare errori. | AWSamministratore |
Eseguire un failback gestito. | Esegui il failback del cluster di database principale nella regione principale. Per istruzioni, consulta Esecuzione di failover pianificati gestiti per i database globali di Amazon Aurora. Una volta completato il failback sul cluster di database principale, esegui la stessa attività sul cluster di database reporter. | AWSamministratore, DBA |
Ottenere il checkpoint di replica. | Per ottenere il checkpoint di replica, utilizzate un SQL client My per interrogare la tabella dei metadati eseguendo quanto segue sul nodo writer nel cluster di database reporter nella regione DR.
Nella tabella, trova il | DBA |
Aggiorna gli endpoint AWS DMS di origine e di destinazione. | Dopo il failback dei cluster di database, controlla i cluster nella regione primaria per determinare quali nodi sono le istanze di scrittura. Quindi verifica che gli endpoint di AWS DMS origine e di destinazione esistenti nella regione primaria puntino alle istanze writer. In caso contrario, aggiorna gli endpoint con i nomi Domain Name System () dell'istanza writer. DNS | AWSamministratore |
Crea un'AWSDMSattività. | Utilizzando la console, crea un'AWSDMSattività nella regione principale. Nell'attività, specifica un metodo di migrazione di Replica solo le modifiche ai dati. Per ulteriori informazioni, vedere Creazione di un'attività.
| AWSamministratore, DBA |
Registra l'AWSDMSattività Amazon Resource Name (ARN). | Usa il ARN per ottenere il nome dell'AWSDMSattività per un uso successivo. Per recuperare l'AWSDMSattivitàARN, esegui il comando seguente:
Il nome dell'attività sarà necessario quando si esegue un altro failover gestito o durante uno scenario di DR. | AWSamministratore, DBA |
Eliminare AWS DMS le attività. | Elimina l'AWSDMSattività originale (attualmente interrotta) nella regione principale e l'AWSDMSattività esistente (attualmente interrotta) nella regione secondaria. | AWSamministratore |
Risorse correlate
Informazioni aggiuntive
I database globali di Amazon Aurora vengono utilizzati in questo esempio per il DR perché forniscono un obiettivo di tempo di ripristino effettivo (RTO) di 1 secondo e un obiettivo del punto di ripristino (RPO) inferiore a 1 minuto, entrambi inferiori rispetto alle soluzioni replicate tradizionali e ideali per scenari di DR.
I database globali di Amazon Aurora offrono molti altri vantaggi, tra cui:
Letture globali con latenza locale: i consumatori globali possono accedere alle informazioni in una regione locale, con latenza locale.
Cluster Amazon Aurora DB secondari scalabili: i cluster secondari possono essere scalati indipendentemente, aggiungendo fino a 16 repliche di sola lettura.
Replica rapida dai cluster Amazon Aurora DB primari a quelli secondari: la replica ha un impatto minimo sulle prestazioni del cluster primario. Si verifica a livello di storage, con latenze di replica tipiche tra regioni inferiori a 1 secondo.
Questo modello viene utilizzato AWS DMS anche per la replica. I database Amazon Aurora offrono la possibilità di creare repliche di lettura, che possono semplificare il processo di replica e la configurazione del DR. Tuttavia, AWS DMS viene spesso utilizzato per la replica quando sono necessarie trasformazioni dei dati o quando il database di destinazione richiede indici aggiuntivi che il database di origine non dispone.
