Elevata disponibilità di Amazon Aurora
L'architettura Amazon Aurora prevede la separazione tra archiviazione e calcolo. Aurora include alcune funzionalità per l'alta disponibilità applicabili ai dati nel cluster database. I dati restano protetti anche se alcune o tutte le istanze database nel cluster smettono di essere disponibili. Altre funzionalità per l'alta disponibilità sono applicabili alle istanze database. Queste funzionalità assicurano la presenza di una o più istanze database per la gestione delle richieste al database provenienti dall'applicazione.
Argomenti
Elevata disponibilità di dati Aurora
Aurora archivia le copie dei dati in un cluster di database in più zone di disponibilità in una singola Regione AWS. L’archiviazione avviene indipendentemente dal fatto che le istanze nel cluster database siano estese su più zone di disponibilità. Per ulteriori informazioni su Aurora, consulta Gestione di un cluster DB Amazon Aurora.
Quando i dati vengono scritti nell'istanza database primaria, Aurora replica in modo sincrono i dati nelle zone di disponibilità in sei nodi di storage associati al volume cluster. Questa operazione fornisce la ridondanza dei dati, elimina i blocchi I/O e riduce al minimo i picchi di latenza durante i backup di sistema. Eseguendo un'istanza database con disponibilità elevata, è possibile migliorare la disponibilità durante la manutenzione pianificata del sistema e consentire di proteggere i database da errori e interruzioni relative alle zone di disponibilità. Per ulteriori informazioni sulle zone di disponibilità, consulta Regioni e zone di disponibilità.
Architetture ad alta disponibilità per istanze database Aurora
Dopo aver creato l'istanza primaria (scrittura), è possibile creare fino a 15 repliche di Aurora in sola lettura. Le repliche Aurora sono note anche come istanze di lettore. Le repliche Aurora utilizzano la replica asincrona per supportare l’elevata disponibilità senza influire sulle prestazioni dell’istanza primaria.
Durante le operazioni quotidiane, è possibile scaricare parte del lavoro per le applicazioni ad alta intensità di lettura utilizzando le istanze del lettore per elaborare le query SELECT. Quando un problema riguarda l'istanza primaria, una di queste istanze del lettore prende il sopravvento come istanza primaria. Questo meccanismo è noto come failover. Molte funzionalità Aurora si applicano al meccanismo di failover. Ad esempio, Aurora rileva i problemi del database e attiva automaticamente il meccanismo di failover quando necessario. Aurora dispone inoltre di funzionalità che riducono i tempi di completamento del failover. In questo modo si riduce al minimo il tempo in cui il database non è disponibile per la scrittura durante un failover.
Aurora è progettato per eseguire il ripristino il più rapidamente possibile e il percorso più rapido per il ripristino è spesso il riavvio o il failover sulla stessa istanza database. Il riavvio è più rapido e comporta un sovraccarico inferiore rispetto al failover.
Per utilizzare una stringa di connessione che rimane invariata anche quando un failover promuove una nuova istanza primaria, è necessario connettersi all'endpoint del cluster. L'endpoint del cluster rappresenta sempre l'istanza primaria corrente nel cluster. Per ulteriori informazioni sull'endpoint del cluster, consulta Connessioni degli endpoint Amazon Aurora.
Suggerimento
All'interno di ogni Regione AWS, le zone di disponibilità rappresentano posizioni distinte l'una dall'altra per fornire isolamento in caso di interruzioni. È consigliabile distribuire l’istanza primaria e le istanze di lettura nel cluster di database su più zone di disponibilità, in modo da migliorare la disponibilità del cluster di database. In questo modo, un problema che riguarda un’intera zona di disponibilità non causa un’interruzione del cluster.
È possibile impostare un cluster di database Multi-AZ facendo una semplice scelta quando si crea il cluster. Puoi utilizzare il plugin AWS Management Console, la AWS CLI o l'API Amazon RDS. È inoltre possibile convertire un cluster di database Aurora esistente in un cluster di database Multi-AZ aggiungendo una nuova istanza database di lettura e specificando una zona di disponibilità diversa.
Elevata disponibilità nelle regioni AWS con database globali Aurora
Per un'elevata disponibilità in più Regioni AWS, è possibile configurare i database globali Aurora. Ciascun database globale Aurora si estende su più Regioni AWS, consentendo letture globali a bassa latenza e il disaster recovery da interruzioni a livello di Regione AWS. Aurora replica in modo asincrono tutti i dati e gli aggiornamenti dalla Regione AWS primaria in ciascuna delle Regioni secondarie. Per ulteriori informazioni, consulta Utilizzo di Database globale Amazon Aurora.
Tolleranza ai guasti di un cluster DB Aurora
In base alla progettazione, un cluster DB Aurora è tollerante ai guasti. Il volume del cluster è uno si estende su più zone di disponibilità di una singola Regione AWS e ciascuna di esse include una copia dei dati del volume del cluster. Questa funzionalità consente al cluster DB di tollerare il guasto di una zona di disponibilità senza perdita di dati e con solo una breve interruzione del servizio.
In caso di guasto dell'istanza primaria di un cluster di database, Aurora esegue automaticamente il failover su una nuova istanza primaria, adottando uno dei seguenti due metodi:
-
Promuovendo una replica Aurora esistente come nuova istanza primaria.
-
Creando una nuova istanza primaria
Se il cluster di database include una o più repliche di Aurora, una di questeAurora verrà promossa come istanza primaria durante un evento di errore. Un evento di errore ha come conseguenza una breve interruzione, durante la quale le operazioni di lettura e scrittura inviate all'istanza primaria falliscono con un'eccezione. Tuttavia, il servizio viene in genere ripristinato in meno di 60 secondi e spesso in meno di 30 secondi. Per aumentare la disponibilità del cluster DB, consigliamo di creare almeno una o più repliche Aurora in due o più due zone di disponibilità.
Suggerimento
In Aurora MySQL, è possibile migliorare la disponibilità durante un failover se è presente più di un’istanza database di lettura in un cluster. In Aurora MySQL, Aurora riavvia solo l’istanza database di scrittura e l’istanza di lettura in cui si verifica il failover. Altre istanze di lettura nel cluster rimangono disponibili durante un failover per continuare a elaborare le query tramite connessioni all'endpoint di lettura.
È inoltre possibile migliorare la disponibilità durante un failover utilizzando RDS Proxy con il cluster database di Aurora database. Per ulteriori informazioni, consulta Elevata disponibilità con Amazon RDS Proxy.
Puoi personalizzare l'ordine di promozione a istanza principale delle repliche Aurora dopo un guasto assegnando una priorità a ciascuna di esse. Le priorità vanno da 0, quella massima, a 15, quella minima. Se l'istanza primaria non va a buon fine, Amazon RDS promuove la replica di Aurora a istanza primaria con la massima priorità. Puoi modificare la priorità di una replica Aurora in qualsiasi momento. Modificando una priorità non attiverai un failover.
Più repliche Aurora possono condividere la stessa priorità, avendo come risultato livelli di promozione. Se due o più repliche di Aurora condividono la stessa priorità, Amazon RDS promuove quella di dimensioni maggiori. Se due o più repliche di Aurora condividono la stessa priorità e dimensioni, Amazon RDS ne promuove una arbitrariamente nello stesso livello di promozione.
Nota
Nell’identificazione di una destinazione di failover intervengono diversi fattori. Dopo cinque tentativi di failover non riusciti, i livelli di promozione non vengono più presi in considerazione.
Se il cluster database non contiene repliche Aurora, l'istanza primaria viene ricreata nello stesso AZ durante un evento di errore. Un evento di errore ha come conseguenza un'interruzione, durante la quale le operazioni di lettura e scrittura inviate all'istanza primaria falliscono con un'eccezione. Il servizio viene ripristinato quando crei la nuova istanza primaria. In genere, ciò richiede meno di 10 minuti. La promozione di una replica Aurora a istanza primaria è un'operazione molto più veloce rispetto alla creazione di una nuova istanza primaria.
Si assuma che l'istanza primaria nel cluster non sia disponibile a causa di un'interruzione che influisce su una intera zona di disponibilità. In questo caso, il modo per portare online una nuova istanza primaria varia in base all'utilizzo del cluster di una configurazione Multi-AZ:
-
Se il cluster Aurora Serverless v2 o con provisioning contiene istanze di lettore in altre zone di disponibilità, Aurora utilizza il meccanismo di failover per promuovere una di queste istanze di lettura come nuova istanza primaria.
-
Se il cluster Aurora Serverless v2 o con provisioning contiene solo una singola istanza database o se l'istanza primaria e tutte le istanze del lettore si trovano nella stessa zona di disponibilità, dovrai creare manualmente una o più nuove istanze database in un’altra zona di disponibilità.
-
Se il cluster utilizza Aurora Serverless v1, Aurora crea automaticamente una nuova istanza database in un’altra zona di disponibilità. Tuttavia, questo processo comporta una sostituzione dell’host e richiede quindi un tempo di failover maggiore.
Nota
Amazon Aurora supporta anche la replica tramite un database MySQL esterno o un'istanza database RDS MySQL. Per ulteriori informazioni, consulta Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari).
Elevata disponibilità con Amazon RDS Proxy
Con RDS Proxy, è possibile creare applicazioni in grado di tollerare in modo trasparente gli errori del database senza dover scrivere codice di gestione degli errori complesso. Il proxy instrada automaticamente il traffico verso una nuova istanza database preservando le connessioni alle applicazioni. Inoltre, ignora le cache DNS (Domain Name System) per ridurre i tempi di failover fino al 66% per i database Aurora Multi-AZ. Per ulteriori informazioni, consulta Server proxy per Amazon RDS per Aurora.
