Utilizzo degli Amazon Aurora Global Database

Per le procedure operative pianificate come la rotazione delle regioni, utilizza lo switchover globale del database( precedentemente chiamato "failover pianificato gestito"). Con questa caratteristica, puoi trasferire il cluster primario di un database globale Aurora integro in una delle regioni secondarie senza alcuna perdita di dati. Per ulteriori informazioni, consulta Esecuzione di switchover per database globali Amazon Aurora.

Per ripristinare il database globale Aurora dopo un'interruzione nella regione principale, utilizza il failover globale del database. Con questa funzionalità, esegui il failover del cluster database primario in un'altra regione (failover tra regioni). Per ulteriori informazioni, consulta Esecuzione di failover gestiti per database globali Aurora.

Letture globali con latenza locale: se hai uffici in tutto il mondo, puoi utilizzare un database globale Aurora per mantenere aggiornate le principali fonti di informazioni nel sistema primario Regione AWS. Gli uffici delle altre regioni possono accedere alle informazioni nella propria regione, con latenza locale.

Cluster Aurora DB secondari scalabili: puoi scalare i tuoi cluster secondari aggiungendo più istanze di sola lettura (Repliche Aurora) a un cluster secondario Regione AWS. Il cluster secondario è di sola lettura, quindi può supportare fino a 16 istanze Aurora Replica di sola lettura anziché il normale limite di 15 per un singolo cluster Aurora.

Replica rapida dai cluster di database Aurora primari a quelli secondari – La replica eseguita da un database globale Aurora ha un impatto ridotto sulle prestazioni del cluster di database primario. Le risorse delle istanze database sono totalmente dedicate a servire carichi di lavoro di lettura e scrittura delle applicazioni.

Ripristino da interruzioni a livello regionale: i cluster secondari consentono di rendere disponibile un database globale Aurora in un nuovo database primario Regione AWS più rapidamente (inferioreRTO) e con una minore perdita di dati (inferioreRPO) rispetto alle soluzioni di replica tradizionali.

I database globali di Aurora sono disponibili in alcuni Regioni AWS e solo per versioni specifiche di Aurora My e SQL Aurora Postgre. SQL Per ulteriori informazioni, consulta Regioni e motori DB supportati per i database globali Aurora.

I database globali Aurora hanno requisiti di configurazione specifici per le classi di istanze Aurora DB supportate, numero massimo di Regioni AWS e così via. Per ulteriori informazioni, consulta Requisiti di configurazione di un database globale Amazon Aurora.

Per la compatibilità con Aurora My SQL con My SQL 5.7, gli switchover del database globale di Aurora richiedono la versione 2.09.1 o una versione secondaria successiva.

È possibile eseguire switchover o failover gestiti tra regioni su un database globale Aurora solo se i cluster DB primari e secondari hanno le stesse versioni del motore principale, secondaria e a livello di patch. Tuttavia, i livelli di patch possono essere diversi se la versione secondaria del motore è una delle seguenti.

Per ulteriori informazioni, consulta Compatibilità del livello di patch per switchover e failover gestiti tra regioni.

I database globali Aurora attualmente non supportano le seguenti funzionalità di Aurora:

Per le limitazioni relative all'utilizzo della funzionalità RDS Proxy con database globali, vedere. Limitazioni di Server proxy per RDS con i database globali

L'aggiornamento automatico della versione secondaria non si applica ai SQL cluster Aurora My e SQL Aurora Postgre che fanno parte di un database globale Aurora. Si noti che questa impostazione può essere specificata per un'istanza database che fa parte di un cluster di database globale, ma l'impostazione non ha effetto.

I database globali Aurora attualmente non supportano l’Auto Scaling Aurora per i cluster di database secondari.

Per utilizzare i flussi di attività del database sui database globali di Aurora che eseguono Aurora SQL My 5.7, la versione del motore deve essere la versione 2.08 o successiva. Per informazioni sui flussi di attività di database, consulta Monitoraggio di Aurora con flussi di attività del database.

Le seguenti limitazioni si applicano attualmente ai database globali Aurora:

Per informazioni sull'aggiornamento di un database globale Aurora, consulta Aggiornamento di un database globale Amazon Aurora.

Non è possibile interrompere o avviare i cluster di database Aurora nel database globale Aurora in modo individuale. Per ulteriori informazioni, consulta Avvio e arresto di un cluster di database Amazon Aurora.

Le repliche Aurora collegate al cluster di database Aurora secondario possono essere riavviate in determinate circostanze. Se il primario Regione AWS L'istanza Writer DB si riavvia o esegue il failover, inoltre le repliche di Aurora nelle regioni secondarie vengono riavviate. Il cluster secondario non sarà quindi disponibile fino a quando tutte le repliche sono nuovamente sincronizzate con l'istanza di scrittura del cluster di database primario. Il comportamento del cluster primario durante il riavvio o il failover è uguale a quello di un singolo cluster di database non globale. Per ulteriori informazioni, consulta Replica con Amazon Aurora.

Prima di apportare modifiche al cluster di database primario, assicurarsi di comprendere l'impatto sul database globale Aurora. Per ulteriori informazioni, consulta Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata.

I database globali di Aurora attualmente non supportano lo inaccessible-encryption-credentials-recoverable stato quando Amazon Aurora perde l'accesso a AWS KMS chiave per il cluster DB. In questi casi, il cluster database crittografato entra nello stato terminale inaccessible-encryption-credentials. Per ulteriori informazioni su questi stati, consulta Visualizzazione dello stato del cluster del DB.

I cluster DB SQL basati su Aurora Postgre in esecuzione in un database globale Aurora presentano le seguenti limitazioni: