Utilizzo dello switchover o failover in un Database globale Amazon Aurora

La funzionalità Database globale Aurora offre una maggiore protezione a livello di continuità aziendale e disaster recovery (BCDR) rispetto alla disponibilità elevata standard fornita da un cluster di database Aurora in una singola Regione AWS. Database globale Aurora consente di pianificare un ripristino più rapido in caso di rari eventi non pianificati o di interruzioni complete dei livelli di servizio a livello regionale.

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

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 applicano alle funzionalità del Database globale Aurora.

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

L’esecuzione di uno switchover o failover con Database globale Aurora implica la promozione di un cluster di database secondario a cluster di database primario. 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 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.

Durante uno switchover, Aurora imposta il cluster nella Regione secondaria scelta come cluster primario. 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 tutti i cluster della Regione secondaria di destinazione siano completamente sincronizzati con il cluster della Regione primaria. In seguito, il cluster di database nella Regione primaria diventa di sola lettura. Il cluster secondario scelto promuove uno dei suoi nodi di sola lettura allo stato di scrittura completo, consentendo così al cluster secondario di assumere il ruolo di cluster primario. Poiché tutti i cluster secondari di destinazione sono stati sincronizzati con quello primario all’inizio del processo, il nuovo 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 utilizzi l’endpoint di scrittura del Database globale Aurora, non occorre cambiare 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 cluster primario precedente, anziché l’endpoint di scrittura globale. In tal caso, assicurati di modificare le impostazioni di connessione dell’applicazione in modo da 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 Server proxy per RDS, assicurati di reindirizzare le operazioni di scrittura dell’applicazione all’endpoint di lettura/scrittura appropriato del proxy associato al nuovo cluster primario. Questo endpoint del proxy può essere l'endpoint predefinito o un endpoint di lettura/scrittura personalizzato. Per ulteriori informazioni, consulta Come funzionano gli endpoint Server proxy per RDS con i database globali.

Puoi eseguire lo switchover del Database globale Aurora utilizzando la Console di gestione AWS, la AWS CLI o l’API RDS.

Esecuzione dello switchover nel database globale Aurora

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

2. Scegli Database e individua 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

Utilizza il comando CLI switchover-global-cluster per eseguire lo switchover per il Database globale Aurora. Questo comando consente di passare i valori per i seguenti parametri.

• --region: specifica la Regione AWS in cui è in esecuzione il cluster di database 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 Linux, macOS o Unix:

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 lo switchover per il Database globale Aurora, esegui l’operazione API SwitchoverGlobalCluster.

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

In rare occasioni, per il Database globale Aurora potrebbe verificarsi un’interruzione inaspettata nella Regione AWS primaria. 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.

Database globale Aurora offre due metodi di failover da 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 scelta 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 precedente 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 primaria corrente. Poiché il Database globale Aurora replica i dati in modo asincrono, è possibile che non tutte le transazioni vengano replicate nella Regione AWS secondaria scelta prima della promozione per 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 precedente Regione primaria dopo il ripristino. Prima di creare il nuovo volume di archiviazione nella Regione AWS, Aurora tenta di acquisire uno snapshot del volume di archiviazione precedente nel punto in cui si è verificato l’errore. Questo consente di ripristinare lo snapshot e recuperare i dati mancanti. Se questa operazione ha esito positivo, Aurora inserisce questo snapshot denominato rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp nella sezione Snapshot della Console di gestione AWS. È inoltre possibile utilizzare il comando AWS CLI describe-db-cluster-snapshots o l’operazione API DescribeDBClusterSnapshots per visualizzare i dettagli dello snapshot.

Quando si avvia un failover gestito, Aurora tenta anche di arrestare il traffico di scrittura nel livello di archiviazione Aurora ad alta disponibilità. Questo meccanismo è chiamato “write fencing”. Se il processo ha esito positivo, Aurora emette un evento RDS per indicare 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 abbia esito positivo tempestivamente. In tal caso, Aurora emette un evento RDS che informa l’utente che si è verificato il timeout del processo di interruzione delle scritture. Se il cluster primario precedente è raggiungibile sulla rete, Aurora vi registra questi eventi. In caso contrario, Aurora registra gli eventi sul nuovo cluster primario. Per ulteriori informazioni su questi eventi, consulta Eventi di cluster di database. Poiché il fencing di scritture è un tentativo migliore possibile, è possibile che le scritture vengano momentaneamente accettate nella Regione primaria precedente, causando problemi di tipo split-brain.

È consigliabile completare le seguenti attività prima di eseguire un failover con Database globale Aurora. In questo modo si riduce al minimo l’incidenza di problemi di tipo split-brain o il ripristino di dati non replicati dallo snapshot del cluster primario precedente.

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 l’istanza database di scrittura della nuova Regione primaria è disponibile, puoi connettervi 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 dati point-in-time del nuovo cluster regionale 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 utilizzi l’endpoint globale, non occorre cambiare 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 utilizzi l’endpoint globale, assicurati di modificare l’endpoint dell’applicazione in modo che utilizzi l’endpoint del cluster per il cluster di database 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 il proxy RDS, assicurati di reindirizzare le operazioni di scrittura dell'applicazione all'endpoint di lettura/scrittura appropriato del proxy associato al nuovo cluster primario. Questo endpoint del proxy può essere l'endpoint predefinito o un endpoint di lettura/scrittura personalizzato. 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 uno snapshot denominato rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp. Questo snapshot è disponibile nella sezione Snapshot di Console di gestione AWS. Questo snapshot è disponibile anche nelle informazioni restituite dall'operazione API DescribeDBClusterSnapshots.

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.

Puoi eseguire un failover con il Database globale Aurora utilizzando la Console di gestione AWS, la AWS CLI o l’API RDS.

Esecuzione del failover gestito nel database globale Aurora

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

2. Scegli Database e individua il Database globale Aurora di 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, potrai visualizzare i cluster di database Aurora e il relativo stato corrente nell’elenco Database, come illustrato nella figura seguente.

Esecuzione del failover gestito nel database globale Aurora

Utilizza il comando della CLI failover-global-cluster per eseguire il failover con il Database globale Aurora. Questo comando consente di passare i valori per i seguenti parametri.

• --region: specifica la Regione AWS in cui è in esecuzione il cluster database secondario che vuoi promuovere a nuovo cluster 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 Linux, macOS o Unix:

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 il Database globale Aurora, esegui l’operazione API FailoverGlobalCluster.

Esecuzione di failover manuali per i 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, puoi usare 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 hai eseguito la riconfigurazione in risposta a un'interruzione di una Regione AWS, puoi nuovamente rendere la Regione AWS come principale dopo la risoluzione dell'interruzione. A tale scopo, aggiungi la precedente Regione AWS al nuovo database globale e quindi usa il processo di switchover per cambiare 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 degli RPO per 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 una nuova Regione AWS dopo un failover. 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 descritto di seguito, puoi monitorare anche le metriche generate. 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 Aurora basati su PostgreSQL.

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 Console di gestione AWS, 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 Linux, macOS o Unix:

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 di database 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 Console di gestione AWS, 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"