Ripristino di un database globale Aurora da un'interruzione non pianificata Esecuzione di switchover per database globali Aurora Gestione RPOs di database globali basati su Aurora SQL Postgre

Utilizzo dello switchover o failover in un database globale Amazon Aurora

Un database globale Aurora offre una maggiore protezione per la continuità aziendale e il disaster recovery (BCDR) rispetto all'alta disponibilità standard fornita da un cluster Aurora DB in un unico cluster. Regione AWS Utilizzando un database globale Aurora, puoi velocizzare l'esecuzione della pianificazione e del ripristino in caso di reali guasti o di interruzioni dei livelli di servizio a livello regionale. Il ripristino di emergenza è in genere determinato dai due obiettivi aziendali seguenti:

Obiettivo del tempo di ripristino (RTO): il tempo impiegato da un sistema per tornare allo stato operativo dopo un disastro o un'interruzione del servizio. In altre parole, RTO misura i tempi di inattività. Per un database globale Aurora, RTO può essere nell'ordine dei minuti.
Recovery Point Objective (RPO): la quantità di dati che possono essere persi (misurata in termini di tempo) dopo un disastro o un'interruzione del servizio. Questa perdita di dati è in genere dovuta al ritardo della replica asincrona. Per un database globale Aurora, RPO viene in genere misurato in secondi. Con un database globale SQL basato su Aurora Postgre, è possibile utilizzare il rds.global_db_rpo parametro per impostare e tenere traccia del limite superioreRPO, ma ciò potrebbe influire sull'elaborazione delle transazioni sul nodo di scrittura del cluster primario. Per ulteriori informazioni, consulta Gestione RPOs di database globali basati su Aurora SQL Postgre.

Lo switchover o il failover di un database globale Aurora implica la promozione a cluster database principale di un cluster database in una delle regioni secondarie del database globale. 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:

Failover: utilizza questo approccio per il ripristino dopo un'interruzione non pianificata. Con questo approccio, puoi eseguire un failover tra regioni su uno dei cluster database secondari del database globale Aurora. Il valore RPO per questo approccio è in genere un valore diverso da zero misurato in secondi. La quantità di perdita di dati dipende dal ritardo di replica del database globale di Aurora Regioni AWS al momento dell'errore. Per ulteriori informazioni, consulta Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata.
Switchover: questa operazione era precedentemente definita "failover pianificato gestito". Usa questo approccio negli scenari controllati, ad esempio durante la manutenzione operativa e altre procedure operative pianificate. Poiché questa funzionalità sincronizza i cluster DB secondari con quelli primari prima di apportare altre modifiche, RPO è 0 (nessuna perdita di dati). Per ulteriori informazioni, consulta Esecuzione di switchover per database globali Amazon Aurora.

Nota

Se desideri eseguire lo switchover o il failover su un cluster database Aurora secondario headless, devi prima aggiungervi un'istanza database. Per ulteriori informazioni sui cluster database headless, consulta Creazione di un cluster database Aurora headless in una regione secondaria.

Argomenti

Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata
Esecuzione di switchover per database globali Amazon Aurora
Gestione RPOs di database globali basati su Aurora SQL Postgre

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 principale. 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 sia i tempi di inattività (RTO) che la perdita di dati (RPO), è possibile eseguire rapidamente un failover tra regioni.

Esistono due metodi per eseguire il failover in una situazione di ripristino di emergenza:

Failover gestito: questo metodo è consigliato in situazioni che prevedono il ripristino di emergenza. Quando si utilizza questo metodo, Aurora aggiunge automaticamente la vecchia regione primaria al database globale come regione secondaria quando diventa nuovamente disponibile. Pertanto, viene mantenuta la topologia originale del cluster globale. Per informazioni su come utilizzare questo metodo, consulta Esecuzione di failover gestiti per database globali Aurora.
Failover manuale: questo metodo alternativo può essere utilizzato quando il failover gestito non è un'opzione, ad esempio quando le regioni primarie e secondarie utilizzano versioni del motore non compatibili. Per informazioni su come utilizzare questo metodo, consulta Esecuzione di failover gestiti per database globali Aurora.

Importante

Entrambi i metodi di failover possono comportare la perdita dei dati delle transazioni di scrittura che non sono stati replicati sul dispositivo secondario scelto prima che si verificasse l'evento di failover. Tuttavia, il processo di ripristino che promuove un'istanza database sul cluster database secondario scelto come istanza database di scrittura principale garantisce che i dati si trovino in uno stato transazionale coerente.

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, per il cluster primario viene eseguito il failover nella regione secondaria scelta, mentre la topologia di replica esistente del database globale Aurora viene mantenuta. 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 risultano mancanti quando questo secondario diventa il nuovo primario.

Nota

È possibile eseguire un failover gestito del database tra regioni su un database globale Aurora solo se i cluster di database primario e secondario hanno la stessa versione principale e secondaria e lo stesso livello di patch del motore. Tuttavia, i livelli di patch possono essere diversi, a seconda della versione secondaria del motore. Per ulteriori informazioni, consulta Compatibilità del livello di patch per switchover e failover gestiti tra regioni. Se le versioni del motore non sono compatibili, puoi eseguire il failover manualmente seguendo i passaggi indicati in Esecuzione di failover gestiti per database globali Aurora.

Per ridurre al minimo la perdita di dati, è consigliabile eseguire le seguenti operazioni prima di utilizzare questa funzionalità:

Mettere le applicazioni offline per impedire l'invio di scritture al cluster primario del database globale Aurora.
Controllare i tempi di ritardo per tutti i cluster di database Aurora secondari nel database globale Aurora. 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. Per tutti i database globali basati su Aurora Postgre e per i database globali SQL basati su Aurora My SQL a partire dalle versioni del motore 3.04.0 e successive, o 2.12.0 e successive, usa Amazon CloudWatch per visualizzare la metrica per tutti i cluster DB secondari. AuroraGlobalDBRPOLag Per le versioni minori inferiori dei database globali SQL basati su Aurora My, visualizza invece la AuroraGlobalDBReplicationLag metrica. Questa metrica indica il ritardo (in millisecondi) della replica tra un cluster secondario e il cluster database primario.

Per ulteriori informazioni sulle CloudWatch metriche per Aurora, consulta. Parametri a livello di cluster per Amazon Aurora

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:

Configura il gruppo di parametri del cluster di database Aurora per il nuovo primario, se necessario – Puoi configurare i gruppi di parametri del cluster di database Aurora in modo indipendente per ogni cluster Aurora del database globale Aurora. Pertanto, quando si promuove un cluster database secondario perché assuma il ruolo primario, il gruppo di parametri dal cluster secondario potrebbe essere configurato in modo diverso rispetto al cluster 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 Modifica dei parametri per un database globale Aurora.
Configura strumenti e opzioni di monitoraggio, come Amazon CloudWatch Events e allarmi: configura il cluster DB promosso con la stessa capacità di registrazione, gli allarmi e così via necessari per il database 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 di database Aurora e sul monitoraggio, consulta Panoramica sul monitoraggio Amazon Aurora.
Configura le integrazioni con altri AWS servizi: se il tuo database globale Aurora si integra AWS con servizi AWS Secrets Manager come AWS Identity and Access Management Amazon S3 AWS Lambda e, devi assicurarti che questi siano configurati in base alle esigenze. Per ulteriori informazioni sull'integrazione dei database globali di Aurora IAM con Amazon S3 e Lambda, consulta. Utilizzo di Amazon Aurora global database con altri servizi AWS Per ulteriori informazioni su Secrets Manager, consulta Come automatizzare la replica dei segreti in AWS Secrets Manager across. Regioni AWS

In genere, il cluster secondario scelto assume il ruolo primario entro pochi minuti. Non appena il nodo 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 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. Assicurati di modificare l'endpoint per l'applicazione in modo che questa utilizzi il nuovo endpoint. 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 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 inserisce questa istantanea denominata «rds: - unplanned-global-failovername-of-old-primary-DB-cluster-timestamp"nella sezione snapshot di. AWS Management ConsoleÈ inoltre possibile visualizzare questa istantanea elencata nelle informazioni restituite dall'operazione D escribeDBCluster API Snapshots.

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 Copia di una snapshot cluster database.

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 il failover del database globale Aurora utilizzando il AWS Management Console, il AWS CLI, o il. RDS API

Esecuzione del failover gestito nel database globale Aurora

Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/.
Scegli Database e individua il database globale Aurora di cui desideri eseguire il failover.
Scegli Switchover o failover database globale nel menu Operazioni.
Scegli Failover (consenti perdita di dati).
Per Nuovo cluster primario, scegli un cluster attivo in uno dei tuoi cluster secondari Regioni AWS come nuovo cluster primario.
Immetti confirm, quindi scegli Conferma.

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

Visualizzazione dell'elenco Database con il database globale selezionato. Il cluster secondario selezionato ora risulta avere il ruolo di cluster principale e il vecchio cluster primario ha il ruolo di cluster secondario.

Esecuzione del failover gestito nel database globale Aurora

Usa il failover-global-cluster CLI comando per eseguire il failover del database globale Aurora. 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— Specificate l'Amazon Resource Name (ARN) del cluster Aurora DB che desiderate promuovere come nuovo database 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.

PerLinux, omacOS: 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 il failover di un database globale Aurora, esegui l'FailoverGlobalClusterAPIoperazione.

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, puoi usare questa procedura manuale per eseguire il failover del database globale nella regione secondaria di destinazione.

Suggerimento

Si consiglia di comprendere questo processo prima di utilizzarlo. Prepara un piano per procedere rapidamente al primo segno di un problema a livello regionale. Puoi essere pronto a identificare la regione secondaria con il minor ritardo di replica utilizzando Amazon CloudWatch regolarmente per tenere traccia dei tempi di ritardo per i cluster secondari. Assicurati di testare il piano per verificare che le procedure siano complete e accurate e che il personale sia addestrato per eseguire un failover in caso di ripristino di emergenza prima che ciò avvenga realmente.

Esecuzione manuale del failover su un cluster secondario dopo un'interruzione non pianificata nell'area principale

Interrompi l'emissione di DML istruzioni e altre operazioni di scrittura sul cluster Aurora DB primario in caso Regione AWS di interruzione.
Identifica un cluster Aurora DB da un secondario da Regione AWS utilizzare come nuovo cluster DB primario. Se hai due o più file secondari Regioni AWS nel tuo database globale Aurora, scegli il cluster secondario con il minor ritardo di replica.
Scollega il cluster di database secondario scelto dal database globale Aurora.

La rimozione di un cluster di database secondario da un database globale Aurora interrompe immediatamente la replica dal primario al secondario e la promuove a cluster di database Aurora con provisioning autonomo con funzionalità di lettura/scrittura complete. Tutti gli altri cluster di database Aurora secondari associati al cluster primario nella regione con interruzione sono ancora disponibili e possono accettare chiamate dall'applicazione. Inoltre consumano risorse. Poiché si sta ricreando il database globale Aurora, rimuovi gli altri cluster di database secondari prima di creare il nuovo database globale Aurora nei passaggi seguenti. In questo modo, si evitano incongruenze di dati tra i cluster di database nel database globale Aurora (problemi di split-brain).

Per i passaggi dettagliati per lo scollegamento, consulta Rimozione di un cluster da un database globale Amazon Aurora.
Riconfigura l'applicazione per inviare tutte le operazioni di scrittura a questo cluster di database Aurora ora autonomo utilizzando il nuovo endpoint. Se sono stati accettati i nomi forniti al momento della creazione del database globale Aurora, puoi modificare l'endpoint rimuovendo -ro dalla stringa endpoint del cluster 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 scollegato dal database globale Aurora.

Questo cluster di database Aurora diventa il cluster primario di un nuovo database globale Aurora quando si inizia ad aggiungere regioni nel passaggio successivo.

Se utilizzi RDS Proxy, 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.
Aggiungi un file Regione AWS al cluster DB. Quando esegui questa operazione, inizia il processo di replica da primario a secondario. Per i passaggi dettagliati per aggiungere una regione, consulta Aggiungere un file Regione AWS a un database globale di Amazon Aurora.
Aggiungine altro Regioni AWS se necessario per ricreare la topologia necessaria per supportare l'applicazione.

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, aggiungi la precedente Regione AWS al nuovo database globale e quindi usa il processo di switchover per cambiare il ruolo. Il database globale di Aurora deve utilizzare una versione di Aurora Postgre o SQL Aurora My che supporti gli switchover. SQL Per ulteriori informazioni, consulta Esecuzione di switchover per database globali Amazon Aurora.

Esecuzione di switchover per database globali Amazon Aurora

Nota

Gli switchover erano precedentemente denominati "failover pianificati gestiti".

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 "" multiregionali. follow-the-sun 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 zero-data-loss metodo per tornare alla regione principale originale dopo un failover.

Nota

Gli switchover sono progettati per essere utilizzati su un database globale Aurora integro. Per eseguire il ripristino da un'interruzione non pianificata, puoi eseguire la procedura appropriata descritta in Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata.

Per eseguire uno switchover, il cluster database secondario di destinazione deve eseguire la stessa versione del motore del cluster primario, incluso il livello di patch, a seconda della versione del motore. Per ulteriori informazioni, consulta Compatibilità del livello di patch per switchover e failover gestiti tra regioni. Prima di iniziare lo switchover, controlla le versioni del motore nel cluster globale per assicurarti che supportino lo switchover gestito tra regioni e, se necessario, aggiornale.

Durante uno switchover gestito, per il cluster primario viene eseguito lo switchover nella regione secondaria scelta, mentre la topologia di replica esistente del database globale viene mantenuta. Prima di avviare il processo di switchover, Aurora attende che tutti i cluster regionali secondari siano completamente sincronizzati con il cluster regionale primario. 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 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à:

Esegui questa operazione durante le ore non di punta o in un altro momento quando le scritture nel cluster DB primario sono minime.
Mettere le applicazioni offline per impedire l'invio di scritture al cluster primario del database globale Aurora.
Controllare i tempi di ritardo per tutti i cluster di database Aurora secondari nel database globale Aurora. Per tutti i database globali basati su Aurora Postgre e per i database globali SQL basati su Aurora My SQL a partire dalle versioni del motore 3.04.0 e successive o 2.12.0 e successive, usa Amazon CloudWatch per visualizzare la metrica per tutti i cluster DB secondari. AuroraGlobalDBRPOLag Per le versioni minori inferiori dei database globali SQL basati su Aurora My, visualizza invece la AuroraGlobalDBReplicationLag metrica. Questa metrica indica il ritardo (in millisecondi) della replica tra un cluster secondario e il cluster database primario. Il suo valore è direttamente proporzionale al tempo necessario ad Aurora per completare lo switchover. Di conseguenza, maggiore è il valore del ritardo, maggiore sarà il tempo necessario per lo switchover.

Per ulteriori informazioni sulle CloudWatch metriche per Aurora, consulta. Parametri a livello di cluster per Amazon Aurora

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

Configura il gruppo di parametri del cluster di database Aurora per il nuovo primario, se necessario – Puoi configurare i gruppi di parametri del cluster di database Aurora in modo indipendente per ogni cluster Aurora del database globale Aurora. 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 Modifica dei parametri per un database globale Aurora.
Configura strumenti e opzioni di monitoraggio, come Amazon CloudWatch Events e allarmi: configura il cluster DB promosso con la stessa capacità di registrazione, gli allarmi e così via necessari per il database 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 secondarie. 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 sui cluster di database Aurora e sul monitoraggio, consulta Panoramica sul monitoraggio Amazon Aurora.
Configura le integrazioni con altri AWS servizi: se il tuo database globale Aurora si integra AWS con servizi AWS Secrets Manager come AWS Identity and Access Management Amazon S3 AWS Lambda e, assicurati di configurare le integrazioni con questi servizi in base alle esigenze. Per ulteriori informazioni sull'integrazione dei database globali di Aurora IAM con Amazon S3 e Lambda, consulta. Utilizzo di Amazon Aurora global database con altri servizi AWS Per ulteriori informazioni su Secrets Manager, consulta Come automatizzare la replica dei segreti in AWS Secrets Manager across. Regioni AWS

Nota

In genere, lo switchover del ruolo può richiedere fino a diversi minuti. Tuttavia, la creazione di cluster secondari aggiuntivi può richiedere da alcuni minuti a diverse ore, a seconda delle dimensioni del database e della distanza fisica tra le regioni.

Al termine del processo di switchover, il cluster database Aurora promosso può gestire le operazioni di scrittura per il database globale Aurora. Assicurati di modificare l'endpoint per l'applicazione in modo che questa utilizzi il nuovo endpoint. 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.

È possibile passare al database globale di Aurora utilizzando il AWS Management Console, il AWS CLI, o il. RDS API

Esecuzione dello switchover nel database globale Aurora

Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/.
Scegli Database e individua il database globale Aurora di cui desideri eseguire lo switchover.
Scegli Switchover o failover database globale nel menu Operazioni.
Scegli Switchover.
Per Nuovo cluster primario, scegli un cluster attivo in uno dei tuoi cluster secondari Regioni AWS come nuovo cluster primario.
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

Usa il switchover-global-cluster CLI comando per passare al tuo database globale Aurora. Questo comando consente di passare i valori per i seguenti parametri.

--region— Specificare la Regione AWS posizione in cui è in esecuzione il cluster DB primario del database globale Aurora.
--global-cluster-identifier – Specifica il nome del database globale Aurora.
--target-db-cluster-identifier— Specificate l'Amazon Resource Name (ARN) del cluster Aurora DB che desiderate promuovere come principale per il database globale di Aurora.

PerLinux, omacOS: 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 passare a un database globale Aurora, esegui l'SwitchoverGlobalClusterAPIoperazione.

Gestione RPOs di database globali basati su Aurora SQL Postgre

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

Quando si imposta un RPO database SQL globale basato su Aurora Postgre, Aurora monitora il tempo di RPO ritardo di tutti i cluster secondari per assicurarsi che almeno un cluster secondario rimanga all'interno della finestra di destinazione. RPO RPOil tempo di ritardo è un'altra metrica basata sul tempo.

RPOViene utilizzato quando il database riprende le operazioni in un nuovo database dopo un failover. Regione AWS Aurora valuta RPO e RPO ritarda i tempi di esecuzione (o blocco) delle transazioni sul primario nel modo seguente:

Esegue il commit della transazione se almeno un cluster DB secondario ha un tempo di RPO ritardo inferiore a. RPO
Blocca la transazione se tutti i cluster DB secondari presentano tempi di RPO ritardo superiori a. RPO Registra inoltre l'evento nel file di SQL registro di Postgre ed emette eventi di «attesa» che mostrano le sessioni bloccate.

In altre parole, se tutti i cluster secondari sono arretrati rispetto all'obiettivoRPO, Aurora sospende le transazioni sul cluster primario fino a quando almeno uno dei cluster secondari non recupera il ritardo. Le transazioni sospese vengono riprese e confermate non appena il tempo di ritardo di almeno un cluster DB secondario diventa inferiore al. RPO Il risultato è che nessuna transazione può essere confermata finché non viene soddisfatta. 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.

Importante

In un database globale con solo due regioni, consigliamo di mantenere il valore predefinito del parametro rds.global_db_rpo nel gruppo di parametri della regione secondaria. In caso contrario, il failover in questa regione a causa della perdita della regione principale potrebbe causare la sospensione delle transazioni da parte di Aurora. Attendi invece che Aurora completi la ricostruzione del cluster nella vecchia regione in cui si è verificata l'errore prima di modificare questo parametro per imporre il massimo. RPO

Se si imposta questo parametro come descritto di seguito, è possibile monitorare anche i parametri generati. È possibile farlo utilizzando psql o un altro strumento per interrogare il cluster DB primario del database globale Aurora e ottenere informazioni dettagliate sulle operazioni del database globale basato su Aurora Postgre. SQL Per scoprire come, consulta Monitoraggio dei database globali basati su Aurora SQL Postgre.

Argomenti

Impostazione dell'obiettivo del punto di ripristino
Visualizzazione dell'obiettivo del punto di ripristino
Disattivazione dell'obiettivo del punto di ripristino

Impostazione dell'obiettivo del punto di ripristino

Il rds.global_db_rpo parametro controlla l'RPOimpostazione per un database Postgre. SQL Questo parametro è supportato da Aurora Postgre. SQL 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, potresti voler attendere fino a 10 minuti per il tuoRPO, nel qual caso imposti il valore su 600.

È possibile impostare questo valore per il database globale SQL basato su Aurora Postgre utilizzando il AWS Management Console, il, o il. AWS CLI RDS API

Per impostare il RPO

Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/.
Sceglie il cluster primario del database Aurora globale e apri la scheda Configurazione per trovare il relativo gruppo di parametri del cluster di database. Ad esempio, il gruppo di parametri predefinito per un cluster DB primario che esegue Aurora SQL Postgre 11.7 è. default.aurora-postgresql11

I gruppi di parametri non possono essere modificati direttamente. Puoi invece procedere come descritto di seguito:
- Crea un gruppo di parametri cluster di database personalizzato utilizzando il gruppo di parametri predefinito appropriato come punto di partenza. Ad esempio, crea un gruppo di parametri cluster di database personalizzato basato su default.aurora-postgresql11.
- Nel gruppo di parametri database personalizzato, imposta il valore del parametro rds.global_db_rpo in modo da soddisfare il caso d'uso. I valori validi vanno da 20 secondi fino al valore intero massimo di 2.147.483.647 (68 anni).
- Applica il gruppo di parametri del cluster di database modificato al cluster di database Aurora.

Per ulteriori informazioni, consulta Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora.

Per impostare il rds.global_db_rpo parametro, utilizzate il comando -group. modify-db-cluster-parameter CLI Nel comando, specifica il nome del gruppo di parametri del cluster primario e i valori per il RPO parametro.

L'esempio seguente imposta il valore RPO a 600 secondi (10 minuti) per il gruppo di parametri denominato del cluster DB primariomy_custom_global_parameter_group.

Per LinuxmacOS, oUnix:


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"

Per Windows:


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"

Per modificare il rds.global_db_rpo parametro, utilizza l'odifyDBClusterParameterGroupAPIoperazione Amazon RDS M.

Visualizzazione dell'obiettivo del punto di ripristino

L'obiettivo del punto di ripristino (RPO) di un database globale viene archiviato nel rds.global_db_rpo parametro per ogni cluster DB. 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)

La risposta successiva proviene da un cluster DB secondario con RPO impostazione di 1 minuto.


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

Puoi anche usare per CLI ottenere valori per scoprire se rds.global_db_rpo è attivo su uno qualsiasi dei cluster Aurora DB utilizzando per ottenere i valori di tutti i user parametri per il CLI cluster.

PerLinux, omacOS: 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 DB in Amazon Aurora.

Disattivazione dell'obiettivo del punto di ripristino

Per disabilitareRPO, reimpostare il rds.global_db_rpo parametro. È possibile ripristinare i parametri utilizzando il AWS Management Console, il AWS CLI, o il RDSAPI.

Per disabilitare il RPO

Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/.
Nel riquadro di navigazione scegliere Parameter groups (Gruppi di parametri).
Nell'elenco scegliere il gruppo di parametri cluster DB primario.
Scegliere Edit parameters (Modifica parametri).
Scegliere la casella accanto al parametro rds.global_db_rpo.
Scegliere Reimposta.
Quando la schermata mostra Reimposta parametri nel gruppo di parametri DB, scegliere Reimposta parametri.

Per ulteriori informazioni su come reimpostare un parametro con la console, vedere Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora.

Per reimpostare il rds.global_db_rpo parametro, usa il comando reset-db-cluster-parameter-group.

Per LinuxmacOS, oUnix:


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"

Per Windows:


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"

Per reimpostare il rds.global_db_rpo parametro, utilizza l'esetDBClusterParameterGroupoperazione Amazon RDS API R.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Utilizzo dell'inoltro di scrittura in Aurora Postgre SQL

Monitoraggio di un database globale Aurora