Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzo del database globale Amazon Aurora
Con la funzionalità Amazon Aurora Global Database, puoi configurare più cluster Aurora DB che si estendono su più cluster. Regioni AWS Aurora sincronizza automaticamente tutte le modifiche apportate nel cluster DB primario con uno o più cluster secondari. Un database globale Aurora ha un cluster DB primario in una regione e fino a 10 cluster DB secondari in diverse regioni. Questa configurazione multiregionale offre un ripristino rapido da rare interruzioni che potrebbero interessare un'intera area. Regione AWS La disponibilità di una copia completa di tutti i dati in più aree geografiche consente inoltre operazioni di lettura a bassa latenza per le applicazioni che si connettono da località molto diverse in tutto il mondo.
Argomenti
Panoramica del database globale di Amazon Aurora
Utilizzando la funzionalità Amazon Aurora Global Database, puoi eseguire le tue applicazioni distribuite a livello globale utilizzando un singolo database Aurora che si estende su più database. Regioni AWS
Un database globale Aurora è costituito da un database primario Regione AWS in cui vengono scritti i dati e fino a 10 secondari di sola lettura. Regioni AWS Eseguite operazioni di scrittura sul cluster DB primario nel cluster primario. Regione AWS Il modo più comodo per farlo è connettersi all'endpoint Aurora Global Database writer, che punta sempre al cluster DB primario, anche dopo uno switchover o un failover verso un altro. Regione AWS Dopo ogni operazione di scrittura, Aurora replica i dati sul secondario Regioni AWS utilizzando un'infrastruttura dedicata, con una latenza in genere inferiore a un secondo.
Nel diagramma seguente, è possibile trovare un esempio di database globale Aurora che si estende su due. Regioni AWS
Puoi scalare ogni cluster secondario in modo indipendente, aggiungendo una o più istanze di lettore Aurora per servire carichi di lavoro di sola lettura. Puoi utilizzare le istanze For the Reader Aurora Serverless v2 per una scalabilità ancora più granulare e flessibile.
Solo il cluster primario eseguire operazioni di scrittura. I client che eseguono operazioni di scrittura si connettono all'endpoint di scrittura Aurora Global Database, che punta sempre all'istanza Writer DB del cluster primario. Come illustrato nel diagramma, Aurora utilizza il volume di archiviazione del cluster e non il motore di database per una replica rapida e a basso sovraccarico. Per ulteriori informazioni, consulta Panoramica dell'archiviazione di Amazon Aurora.
Aurora Global Database è progettato per applicazioni con un'impronta mondiale. I cluster DB secondari multipli di sola lettura Regioni AWS aiutano a ottimizzare le operazioni di lettura più vicine agli utenti delle applicazioni. Utilizzando la funzionalità di inoltro della scrittura, è inoltre possibile configurare il database globale in modo che i cluster secondari inviino richieste di scrittura al primario. Per ulteriori informazioni, consulta Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora.
Aurora Global Database supporta due diverse operazioni per modificare la regione del cluster DB primario, a seconda dello scenario: lo switchover di Aurora Global Database e il failover di Aurora Global Database.
-
Per le procedure operative pianificate come la rotazione regionale, utilizzate il meccanismo di switchover (precedentemente chiamato «failover pianificato gestito»). Con questa funzionalità, puoi trasferire il cluster primario di un database globale Aurora sano in una delle sue regioni secondarie senza perdita di dati. Per ulteriori informazioni, consulta Esecuzione di switchover per database globali Amazon Aurora.
-
Per ripristinare l'Aurora Global Database dopo un'interruzione nella regione principale, utilizzate il meccanismo di failover. Con questa funzionalità, si esegue un failover dal cluster DB primario verso un'altra regione (failover tra regioni). Per ulteriori informazioni, consulta Esecuzione di failover gestiti per database globali Aurora.
Vantaggi del database globale di Amazon Aurora
Utilizzando Aurora Global Database, è possibile ottenere i seguenti vantaggi:
Letture globali con latenza locale: se hai uffici in tutto il mondo, puoi utilizzare Aurora Global Database per mantenere aggiornate le tue principali fonti di informazioni in modo primario. Regione AWS Gli uffici nelle altre regioni possono accedere alle informazioni nella propria regione, con una latenza locale.
Cluster Aurora DB secondari scalabili: puoi scalare i tuoi cluster secondari aggiungendo più istanze di sola lettura a un cluster secondario. Regione AWS Il cluster secondario è di sola lettura, quindi può supportare fino a 16 istanze DB di sola lettura anziché il normale limite di 15 per un singolo cluster Aurora.
Replica rapida dai cluster Aurora DB primari a quelli secondari: la replica eseguita da Aurora Global Database ha un impatto minimo sulle prestazioni del cluster DB 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 (RTO inferiore) e con una minore perdita di dati (RPO inferiore) rispetto alle soluzioni di replica tradizionali.
Disponibilità di regioni e versioni
Il supporto e la disponibilità di questa funzionalità variano a seconda delle versioni specifiche di ciascun motore di database Aurora e tra Regioni AWS. Per ulteriori informazioni sulla disponibilità di versioni e regioni con Aurora Global Database, consulta. Regioni e motori DB supportati per i database globali Aurora
Limitazioni del database globale di Amazon Aurora
Le seguenti limitazioni si applicano attualmente ad Aurora Global Database:
Aurora Global Database è disponibile in alcune Regioni AWS e per versioni specifiche di Aurora MySQL e Aurora PostgreSQL. Per ulteriori informazioni, consulta Regioni e motori DB supportati per i database globali Aurora.
Aurora Global Database ha requisiti di configurazione specifici per le classi di istanze Aurora DB supportate, il 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 MySQL con MySQL 5.7, gli switchover di Aurora Global Database richiedono la versione 2.09.1 o una versione secondaria superiore.
-
È possibile eseguire switchover o failover gestiti tra regioni con Aurora Global Database solo se i cluster DB primari e secondari hanno le stesse versioni del motore principale e secondario. A seconda del motore e delle versioni del motore, potrebbe essere necessario che i livelli di patch siano identici oppure i livelli di patch possono essere diversi. Per un elenco dei motori e delle versioni del motore che consentono queste operazioni tra cluster primari e secondari con diversi livelli di patch, vedereCompatibilità del livello di patch per switchover e failover gestiti tra regioni. Se le versioni del motore richiedono livelli di patch identici, è possibile eseguire il failover manualmente seguendo la procedura riportata di seguito. Esecuzione di failover gestiti per database globali Aurora
Aurora Global Database attualmente non supporta le seguenti funzionalità di Aurora:
-
Aurora Serverless v1
-
Backtrack in Aurora
-
Per le limitazioni all'utilizzo della funzionalità RDS Proxy con Aurora Global Database, vedere. Limitazioni di Server proxy per RDS con i database globali
L'aggiornamento automatico della versione secondaria non si applica ai cluster Aurora MySQL e Aurora PostgreSQL che fanno parte di un database globale. 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.
Aurora Global Database attualmente non supporta Aurora Auto Scaling per cluster DB secondari.
Per utilizzare Database Activity Streams (DAS) su Aurora Global Database che esegue Aurora MySQL 5.7, la versione del motore deve essere la versione 2.08 o successiva. Per informazioni su DAS, vedere. Monitoraggio di Amazon Aurora tramite i flussi di attività del database
-
Le seguenti limitazioni si applicano attualmente all'aggiornamento di Aurora Global Database:
Non è possibile applicare un gruppo di parametri personalizzato al cluster di database globale mentre si esegue un aggiornamento della versione principale del database globale Aurora. È possibile creare i gruppi di parametri personalizzati in ciascuna Regione del cluster globale e applicarli manualmente ai cluster regionali dopo l'aggiornamento.
-
Con un database globale Aurora basato su Aurora MySQL, non puoi eseguire un aggiornamento locale da Aurora MySQL versione 2 alla versione 3 se il parametro
lower_case_table_namesè attivato. Per ulteriori informazioni sui metodi disponibili all'uso, consulta Aggiornamenti di una versione principale. Con Aurora Global Database, non è possibile eseguire un aggiornamento della versione principale del motore Aurora PostgreSQL DB se la funzionalità Recovery Point Objective (RPO) è attivata. Per ulteriori informazioni sulla caratteristica RPO, consulta Gestione RPOs di database globali basati su Aurora PostgreSQL.
Con un Aurora Global Database, non è possibile eseguire un aggiornamento di versione minore da Aurora MySQL versione 3.01 o 3.02 a 3.03 o superiore utilizzando il processo standard. Per informazioni dettagliate sul processo da usare, consulta Aggiornamento di Aurora MySQL modificando la versione del motore.
Per informazioni sull'aggiornamento di Aurora Global Database, vedere. Aggiornamento di un database globale Amazon Aurora
Non puoi arrestare o avviare singolarmente i cluster Aurora DB nel tuo database globale. Per ulteriori informazioni, consulta Avvio e arresto di un cluster di database Amazon Aurora.
Le istanze DB del lettore Aurora collegate al cluster Aurora DB secondario possono essere riavviate in determinate circostanze. Se l'istanza DB Regione AWS di scrittura principale viene riavviata o ripristinata, vengono riavviate anche le istanze DB Reader nelle regioni secondarie. Il cluster secondario non sarà quindi disponibile finché tutte le istanze DB di lettura non saranno nuovamente sincronizzate con l'istanza writer del cluster DB primario. Il comportamento del cluster primario durante il riavvio o durante un failover è lo stesso di un singolo cluster DB 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 . Per ulteriori informazioni, consulta Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata.
Aurora Global Database attualmente non supporta lo
inaccessible-encryption-credentials-recoverablestato in cui Amazon Aurora perde l'accesso alla chiave per AWS KMS il cluster DB. In questi casi, il cluster database crittografato entra nello stato terminaleinaccessible-encryption-credentials. Per ulteriori informazioni su questi stati, consulta Visualizzazione dello stato del cluster del DB.-
Secrets Manager non supporta Aurora Global Database. Quando aggiungi una regione a un database globale, devi prima disattivare l'integrazione di Secrets Manager per l'istanza DB.
-
I cluster DB basati su Aurora PostgreSQL che utilizzano Aurora Global Database presentano le seguenti limitazioni:
La gestione della cache del cluster non è supportata per i cluster DB secondari Aurora PostgreSQL che fanno parte dei database globali di Aurora.
-
Se il cluster DB primario del tuo database globale è basato su una replica di un'istanza Amazon RDS PostgreSQL, non puoi creare un cluster secondario. Non tentare di creare un secondario da quel cluster utilizzando l'operazione AWS Management Console, la o l'API AWS CLI.
CreateDBClusterI tentativi di eseguire questa operazione scadono e il cluster secondario non viene creato.
Ti consigliamo di creare cluster DB secondari per i tuoi database globali utilizzando la stessa versione del motore Aurora DB del primario. Per ulteriori informazioni, consulta Creazione di un database globale Amazon Aurora.
