Utilizzo dello switchover o del failover in Amazon Aurora Global Database

La funzionalità Aurora Global Database offre una maggiore protezione di continuità aziendale e disaster recovery (BCDR) rispetto all'elevata disponibilità standard fornita da un cluster Aurora DB in un unico cluster. Regione AWS Utilizzando Aurora Global Database, è possibile pianificare un ripristino più rapido da disastri regionali rari e non pianificati o interruzioni complete dei livelli di servizio in tempi rapidi.

È possibile consultare le seguenti linee guida e procedure per pianificare, testare e implementare la strategia BCDR utilizzando la funzionalità Aurora Global Database.

Pianificazione della continuità aziendale e del disaster recovery

Per pianificare la strategia di continuità aziendale e disaster recovery, è utile comprendere la seguente terminologia di settore e il modo in cui tali termini si riferiscono alle funzionalità di Aurora Global Database.

Il ripristino di emergenza è in genere determinato dai due obiettivi aziendali seguenti:

L'esecuzione di uno switchover o di un failover con Aurora Global Database implica la promozione di un cluster DB secondario come cluster DB principale. Il termine "interruzione a livello regionale" viene spesso utilizzato per descrivere una serie di scenari di errore. Lo scenario peggiore potrebbe essere un'interruzione generalizzata causata da un evento catastrofico che interessa un'area geografica particolarmente estesa. Tuttavia, la maggior parte delle interruzioni è molto più localizzata e riguarda solo un piccolo sottoinsieme di servizi cloud o sistemi dei clienti. Valuta l'ambito dell'interruzione nel suo insieme per assicurarti che il failover tra regioni rappresenti la soluzione più appropriata e scegli il metodo di failover più adatto alla situazione. L'utilizzo del failover o dello switchover dipende dallo scenario di interruzione specifico:

Esecuzione di switchover per database globali Amazon Aurora

Utilizzando gli switchover, è possibile modificare la regione del cluster primario su base regolare. 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.

Durante uno switchover, Aurora imposta il cluster nella regione secondaria prescelta come cluster principale. Il meccanismo di switchover mantiene la topologia di replica esistente del database globale: ha ancora lo stesso numero di cluster Aurora nelle stesse regioni. Prima di avviare il processo di switchover, Aurora attende che i cluster Region secondari di destinazione siano completamente sincronizzati con il Region cluster primario. Quindi, il cluster DB nella regione primaria diventa di sola lettura. Il cluster secondario scelto promuove uno dei suoi nodi di sola lettura allo stato di scrittore completo, il che consente a tale cluster secondario di assumere il ruolo di cluster primario. Poiché il cluster secondario di destinazione è stato sincronizzato con quello primario all'inizio del processo, il nuovo cluster primario continua le operazioni per il database globale Aurora 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, è consigliabile eseguire le seguenti operazioni prima di utilizzare questa funzionalità:

Se si utilizza l'endpoint Aurora Global Database writer, non è necessario modificare le impostazioni di connessione nell'applicazione. Verifica che le modifiche al DNS si siano propagate e che sia possibile connettersi ed eseguire operazioni di scrittura sul nuovo cluster primario. Potrai quindi riprendere la piena operatività dell'applicazione.

Supponiamo che le connessioni alle applicazioni utilizzino l'endpoint cluster del vecchio cluster primario, anziché l'endpoint global writer. In tal caso, assicuratevi di modificare le impostazioni di connessione dell'applicazione per utilizzare l'endpoint cluster del nuovo cluster primario. Se hai accettato i nomi forniti al momento della creazione del database globale Aurora, puoi modificare l'endpoint rimuovendo -ro dalla stringa endpoint del cluster promosso nell'applicazione. Ad esempio, l'endpoint del cluster secondario my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com diventa my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com quando tale cluster viene promosso a primario.

Se utilizzi RDS Proxy, assicurati di reindirizzare le operazioni di scrittura dell'applicazione all'endpoint appropriato. read/write endpoint of the proxy that's associated with the new primary cluster. This proxy endpoint might be the default endpoint or a custom read/write Per ulteriori informazioni, consulta Come funzionano gli endpoint Server proxy per RDS con i database globali.

È possibile eseguire uno switchover di Aurora Global Database utilizzando l'API AWS Management Console AWS CLI, the o RDS.

Esecuzione dello switchover nel database globale Aurora

1. Accedi a AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. Scegli Database e trova il database globale Aurora in cui intendi eseguire lo switchover.

3. Scegli Switchover o failover database globale nel menu Operazioni.

   

4. Scegli Switchover.

   

5. In Nuovo cluster primario, scegli un cluster attivo in una delle Regioni AWS secondarie da promuovere a nuovo cluster primario.

6. Scegli Conferma.

Al termine dello switchover, potrai visualizzare i cluster database Aurora e il relativo stato corrente nell'elenco Database, come illustrato nella figura seguente.

Esecuzione dello switchover nel database globale Aurora

Utilizzate il comando switchover-global-cluster CLI per eseguire uno switchover per Aurora Global Database. Questo comando consente di passare i valori per i seguenti parametri.

• --region— Specificare Regione AWS dove è in esecuzione il cluster DB primario del database globale Aurora.

• --global-cluster-identifier – Specifica il nome del database globale Aurora.

• --target-db-cluster-identifier – Specifica l'Amazon Resource Name (ARN) del cluster di database Aurora che si desidera promuovere come principale per il database globale Aurora.

Per LinuxmacOS, oUnix:

aws rds --region region_of_primary \
   switchover-global-cluster --global-cluster-identifier global_database_id \
  --target-db-cluster-identifier arn_of_secondary_to_promote

Per Windows:

aws rds --region region_of_primary ^
   switchover-global-cluster --global-cluster-identifier global_database_id ^
  --target-db-cluster-identifier arn_of_secondary_to_promote

Per eseguire uno switchover per Aurora Global Database, esegui l'operazione API. SwitchoverGlobalCluster

Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata

In rare occasioni, il database globale Aurora potrebbe subire un'interruzione imprevista del database primario. Regione AWS In questo caso, il cluster database Aurora primario e il relativo nodo di scrittura non sono disponibili e la replica tra il cluster database primario e secondari viene interrotta. Per ridurre al minimo i tempi di inattività (RTO) e la perdita di dati (RPO), puoi eseguire un failover tra regioni.

Aurora Global Database dispone di due metodi di failover che è possibile utilizzare in una situazione di disaster recovery:

Esecuzione di failover gestiti per database globali Aurora

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 secondario nella regione secondaria prescelta diventa il nuovo cluster primario. 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. Non appena la vecchia regione primaria è di nuovo integra e disponibile, Aurora la aggiunge automaticamente al cluster globale come regione secondaria. Pertanto, viene mantenuta la topologia di replica esistente del database globale Aurora.

Il failover gestito non attende la sincronizzazione dei dati tra la regione secondaria scelta e la regione principale corrente. Poiché Aurora Global Database replica i dati in modo asincrono, è possibile che non tutte le transazioni siano state replicate AWS nella regione secondaria scelta prima che questa venga promossa ad accettare funzionalità complete di lettura/scrittura.

Per garantire che i dati siano in uno stato coerente, Aurora crea un nuovo volume di archiviazione per la vecchia regione primaria dopo il ripristino. Prima di creare il nuovo volume di archiviazione nella AWS regione, Aurora tenta di scattare un'istantanea del vecchio volume di archiviazione nel punto in cui si è verificato l'errore. In questo modo, è possibile ripristinare l'istantanea e recuperare i dati mancanti in essa contenuti. Se questa operazione ha esito positivo, Aurora inserisce questa istantanea denominata rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp nella sezione snapshot di. AWS Management ConsoleÈ inoltre possibile utilizzare il describe-db-cluster-snapshots AWS CLI comando o l'operazione DescribeDBClusterSnapshots API per visualizzare i dettagli dell'istantanea.

Quando si avvia un failover gestito, Aurora tenta anche di arrestare il traffico di scrittura attraverso il livello di archiviazione Aurora ad alta disponibilità. Ci riferiamo a questo meccanismo come «write fencing». Se il processo ha esito positivo, Aurora emette un evento RDS che indica che le scritture sono state interrotte. Nell'improbabile eventualità che si verifichino più errori AZ in una regione, è possibile che il processo di write fencing non riesca tempestivamente. In tal caso, Aurora emette un evento RDS che informa l'utente che il processo di interruzione delle scritture è scaduto. Se il vecchio cluster primario è raggiungibile sulla rete, Aurora registra questi eventi lì. In caso contrario, Aurora registra gli eventi sul nuovo cluster primario. Per ulteriori informazioni su questi eventi, consultaEventi di cluster di database. Poiché la scrittura di scherma è il miglior tentativo possibile, è possibile che le scritture vengano momentaneamente accettate nella vecchia regione primaria, con conseguenti problemi cerebrali divisi.

Si consiglia di completare le seguenti attività prima di eseguire un failover con Aurora Global Database. In questo modo si riduce al minimo la possibilità di problemi di split-brain o il ripristino di dati non replicati dall'istantanea del vecchio cluster primario.

Durante un failover 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, è consigliabile risolvere le differenze tra i cluster di database globali Aurora per quanto segue:

In genere, il cluster secondario scelto assume il ruolo primario entro pochi minuti. Non appena la nuova istanza Writer DB di Region principale è disponibile, puoi connettere le tue applicazioni e riprendere i tuoi carichi di lavoro. Dopo aver promosso il nuovo cluster primario, Aurora ricostruisce automaticamente tutti i cluster secondari regionali aggiuntivi.

Poiché i database globali Aurora utilizzano la replica asincrona, il ritardo di replica in ciascuna regione secondaria può variare. Aurora ricostruisce queste regioni secondarie in modo che abbiano esattamente gli stessi point-in-time dati del nuovo cluster di regioni primario. 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 la nuova istanza di scrittura primaria viene promossa e risulta disponibile, il cluster della nuova regione primaria può gestire le operazioni di lettura e scrittura per il database globale Aurora.

Se si utilizza l'endpoint globale, non è necessario modificare le impostazioni di connessione nell'applicazione. Verifica che le modifiche al DNS si siano propagate e che sia possibile connettersi ed eseguire operazioni di scrittura sul nuovo cluster primario. Potrai quindi riprendere la piena operatività dell'applicazione.

Se non stai utilizzando l'endpoint globale, assicurati di modificare l'endpoint dell'applicazione in modo che utilizzi l'endpoint del cluster per il cluster DB primario appena promosso. Se hai accettato i nomi forniti al momento della creazione del database globale Aurora, puoi modificare l'endpoint rimuovendo -ro dalla stringa endpoint del cluster promosso nell'applicazione.

Ad esempio, l'endpoint del cluster secondario my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com diventa my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com quando tale cluster viene promosso a primario.

Se utilizzi RDS Proxy, assicurati di reindirizzare le operazioni di scrittura dell'applicazione all'endpoint appropriato. read/write endpoint of the proxy that's associated with the new primary cluster. This proxy endpoint might be the default endpoint or a custom read/write Per ulteriori informazioni, consulta Come funzionano gli endpoint Server proxy per RDS con i database globali.

Per ripristinare la topologia originale del cluster database globale, Aurora monitora la disponibilità della vecchia regione primaria. Non appena tale regione è di nuovo integra e disponibile, Aurora la aggiunge automaticamente al cluster globale come regione secondaria. Prima di creare il nuovo volume di archiviazione nella vecchia regione primaria, Aurora tenta di acquisire uno snapshot del vecchio volume di archiviazione 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, Aurora crea un'istantanea denominata. rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp È possibile trovare questa istantanea nella sezione Istantanee di. AWS Management Console Puoi anche vedere questa istantanea elencata nelle informazioni restituite dall'operazione dell'API Descrivi DBCluster Snapshots.

Dopo il ripristino della topologia originale, puoi eseguire il failback del database globale nella 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 switchover per database globali Amazon Aurora.

È possibile eseguire un failover con Aurora Global Database utilizzando AWS Management Console l'API, AWS CLI the o RDS.

Esecuzione del failover gestito nel database globale Aurora

1. Accedi a AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. Scegli Database e trova il database globale Aurora in cui desideri eseguire il failover.

3. Scegli Switchover o failover database globale nel menu Operazioni.

   

4. Scegli Failover (consenti perdita di dati).

   

5. In Nuovo cluster primario, scegli un cluster attivo in una delle Regioni AWS secondarie da promuovere a nuovo cluster primario.

6. Immetti confirm, quindi scegli Conferma.

Al termine del failover, è possibile visualizzare i cluster Aurora DB e il loro stato corrente nell'elenco Database, come mostrato nell'immagine seguente.

Esecuzione del failover gestito nel database globale Aurora

Utilizzate il comando failover-global-cluster CLI per eseguire un failover con Aurora Global Database. Questo comando consente di passare i valori per i seguenti parametri.

• --region— Specificare la posizione Regione AWS in cui è in esecuzione il cluster DB secondario che si desidera utilizzare come nuovo primario per il database globale Aurora.

• --global-cluster-identifier – Specifica il nome del database globale Aurora.

• --target-db-cluster-identifier: specifica il nome della risorsa Amazon (ARN) del cluster database Aurora che desideri promuovere a nuovo cluster primario per il database globale Aurora.

• --allow-data-loss: imposta in modo esplicito un'operazione di failover anziché un'operazione di switchover. Un'operazione di failover può causare una perdita di dati se i componenti della replica asincrona non hanno completato l'invio di tutti i dati replicati alla regione secondaria.

Per LinuxmacOS, oUnix:

aws rds --region region_of_selected_secondary \
   failover-global-cluster --global-cluster-identifier global_database_id \
   --target-db-cluster-identifier arn_of_secondary_to_promote \
   --allow-data-loss

Per Windows:

aws rds --region region_of_selected_secondary ^
   failover-global-cluster --global-cluster-identifier global_database_id ^
   --target-db-cluster-identifier arn_of_secondary_to_promote ^
   --allow-data-loss

Per eseguire un failover con Aurora Global Database, esegui FailoverGlobalClusterl'operazione API.

Esecuzione di failover gestiti per database globali Aurora

In alcuni scenari, puoi non essere in grado di utilizzare il processo di failover gestito. Un esempio è quando i cluster database primario e secondari non utilizzano versioni del motore compatibili. In questo caso, è possibile seguire questa procedura manuale per eseguire un failover nella regione secondaria di destinazione.

Assicurati che le scritture delle applicazioni vengano inviate al cluster di database Aurora corretto prima, durante e dopo aver apportato queste modifiche. In questo modo, si evitano incongruenze di dati tra i cluster di database nel database globale Aurora (problemi di split-brain).

Se la riconfigurazione è avvenuta in risposta a un'interruzione in un Regione AWS Regione AWS A tale scopo, aggiungete il vecchio Regione AWS al nuovo database globale e quindi utilizzate il processo di passaggio per cambiarne il ruolo. Il database globale Aurora deve utilizzare una versione di Aurora PostgreSQL o Aurora MySQL che supporti gli switchover. Per ulteriori informazioni, consulta Esecuzione di switchover per database globali Amazon Aurora.

Gestione RPOs di database globali basati su Aurora PostgreSQL

Con un database globale basato su Aurora PostgreSQL, puoi gestire l'obiettivo del punto di ripristino (RPO) per il database globale Aurora utilizzando il parametro rds.global_db_rpo. RPO rappresenta la quantità massima di dati che possono essere persi in caso di interruzione.

Quando si imposta un RPO per il database globale basato su Aurora PostgreSQL–, Aurora controlla il tempo di ritardo RPO di tutti i cluster secondari per assicurarsi che almeno un cluster secondario rimanga all'interno della finestra RPO di destinazione. Il tempo di ritardo RPO è un altro parametro basato sul tempo.

L'RPO viene utilizzato quando il database riprende le operazioni in un nuovo database dopo un failover. Regione AWS Aurora valuta i tempi di ritardo RPO e RPO per eseguire il commit (o il blocco) delle transazioni sulla regione principale come segue:

In altre parole, se tutti i cluster secondari sono dietro l'RPO di destinazione, Aurora sospende le transazioni sul cluster primario fino al raggiungimento di almeno uno dei cluster secondari. Le transazioni in pausa vengono nuovamente eseguite non appena il tempo di ritardo di almeno un cluster di database secondario diventa inferiore all'RPO. Il risultato è che nessuna transazione può eseguire il commit fino al raggiungimento dell'RPO.

Il parametro rds.global_db_rpo è dinamico. Se decidi che non vuoi che tutte le transazioni di scrittura si blocchino fino a quando il ritardo non diminuisce a un livello sufficiente, puoi ripristinarlo rapidamente. In questo caso, Aurora riconosce e implementa la modifica dopo un breve ritardo.

Se imposti questo parametro come indicato di seguito, puoi anche monitorare le metriche che genera. Puoi eseguire questa operazione utilizzando psql o un altro strumento per interrogare il cluster di database primario del database globale Aurora e ottenere informazioni dettagliate sulle operazioni del database globale basato su Aurora PostgreSQL–. Per scoprire come, consulta Monitoraggio dei database globali basati su Aurora SQL Postgre.

Impostazione dell'obiettivo del punto di ripristino

Il parametro rds.global_db_rpo controlla l'impostazione RPO per un database PostgreSQL. Questo parametro è supportato da Aurora PostgreSQL. I valori validi per rds.global_db_rpo vanno da 20 secondi a 2.147.483.647 secondi (68 anni). Scegli un valore realistico per soddisfare le tue esigenze aziendali e il caso d'uso. Ad esempio, puoi consentire fino a 10 minuti per l'RPO, nel qual caso si imposta il valore su 600.

Puoi impostare questo valore per il database globale basato su Aurora PostgreSQL utilizzando la AWS Management Console, la AWS CLI o l’API RDS.

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my_custom_global_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my_custom_global_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

Visualizzazione dell'obiettivo del punto di ripristino

L'obiettivo del punto di ripristino (RPO) di un database globale viene memorizzato nel parametro rds.global_db_rpo. Puoi connettersi all'endpoint per il cluster secondario che si desidera visualizzare e utilizzare per psql eseguire una query sull'istanza per questo valore.

db-name=>show rds.global_db_rpo;

Se questo parametro non è impostato, la query restituirà quanto segue:

rds.global_db_rpo
-------------------
 -1
(1 row)

Questa risposta successiva proviene da un cluster di database secondario con impostazione RPO di 1 minuto.

rds.global_db_rpo
-------------------
 60
(1 row)

Puoi inoltre utilizzare la CLI per ottenere valori per scoprire se rds.global_db_rpo è attivo su uno qualsiasi dei cluster di database Aurora utilizzando l'interfaccia a riga di comando per ottenere i valori di tutti i parametri user per il cluster.

Per LinuxmacOS, oUnix:

aws rds describe-db-cluster-parameters \
 --db-cluster-parameter-group-name lab-test-apg-global \
 --source user

Per Windows:

aws rds describe-db-cluster-parameters ^
 --db-cluster-parameter-group-name lab-test-apg-global *
 --source user

Il comando restituisce un output simile al seguente per tutti i parametri user che non sono parametri del cluster di database default-engine o system.

{
    "Parameters": [
        {
            "ParameterName": "rds.global_db_rpo",
            "ParameterValue": "60",
            "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.",
            "Source": "user",
            "ApplyType": "dynamic",
            "DataType": "integer",
            "AllowedValues": "20-2147483647",
            "IsModifiable": true,
            "ApplyMethod": "immediate",
            "SupportedEngineModes": [
                "provisioned"
            ]
        }
    ]
}

Per ulteriori informazioni sulla visualizzazione dei parametri del gruppo di parametri del cluster, consulta Visualizzazione dei valori dei parametri per un gruppo di parametri del cluster DB in Amazon Aurora.

Disattivazione dell'obiettivo del punto di ripristino

Per disabilitare l'RPO, reimpostare il parametro rds.global_db_rpo. È possibile reimpostare i parametri utilizzando AWS Management Console, AWS CLI o l’API RDS.

aws rds reset-db-cluster-parameter-group \
    --db-cluster-parameter-group-name global_db_cluster_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

aws rds reset-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name global_db_cluster_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"