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à.
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.
Durante day-to-day le operazioni, è possibile scaricare parte del lavoro per applicazioni che richiedono un uso intensivo della 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 è progettata 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 DB. 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 Gestione delle connessioni Amazon Aurora.
Suggerimento
All'interno di ciascuna Regione AWS, le zone di disponibilità (AZ) rappresentano località distinte l'una dall'altra per garantire l'isolamento in caso di interruzioni. Consigliamo di 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 configurare un cluster DB Multi-AZ effettuando una scelta semplice al momento della creazione del cluster. Puoi utilizzare il plugin AWS Management Console, la AWS CLI o l'API Amazon RDS. È inoltre possibile convertire un cluster Aurora DB esistente in un cluster DB Multi-AZ aggiungendo una nuova istanza DB reader e specificando una zona di disponibilità diversa.
Elevata disponibilità nelle regioni AWS con database globali Aurora
Per un'elevata disponibilità su più piattaforme Regioni AWS, puoi configurare i database globali Aurora. Ogni database globale Aurora si estende su più database Regioni AWS, consentendo letture globali a bassa latenza e disaster recovery in caso di interruzioni su un. Regione AWS Aurora gestisce automaticamente la replica di tutti i dati e gli aggiornamenti dalla regione primaria Regione AWS a ciascuna delle regioni secondarie. Per ulteriori informazioni, consulta Utilizzo degli Amazon Aurora Global Database.
Tolleranza ai guasti di un cluster DB Aurora
In base alla progettazione, un cluster DB Aurora è tollerante ai guasti. Il volume del cluster si estende su più zone di disponibilità (AZ) in un'unica Regione AWS zona e ogni zona di disponibilità contiene 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 2.10 e versioni successive, è possibile migliorare la disponibilità durante un failover se è presente più di un'istanza DB di lettura in un cluster. In Aurora MySQL 2.10 e versioni successive, Aurora riavvia solo l'istanza database di scrittura e la destinazione dell'istanza di lettura in cui esegue 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.
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 Utilizzo di Server proxy per Amazon RDS per Aurora.
