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 delegare parte del lavoro ad 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 è 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 Connessioni endpoint Amazon Aurora.
Suggerimento
All'interno di ciascuna di esse Regione AWS, le zone di disponibilità (AZs) rappresentano ubicazioni 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 usare il AWS Management Console, il AWS CLI, o Amazon RDSAPI. È 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à (AZs) in un'unica Regione AWS zona di disponibilità 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 My SQL 2.10 e versioni successive, è possibile migliorare la disponibilità durante un failover disponendo di più di un'istanza Reader DB in un cluster. In Aurora My SQL 2.10 e versioni successive, Aurora riavvia solo l'istanza Writer DB e l'istanza reader su 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 Aurora DB. Per ulteriori informazioni, consulta Disponibilità elevata 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 si guasta, Amazon RDS promuove la replica Aurora con la massima priorità rispetto alla nuova istanza primaria. 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 Aurora condividono la stessa priorità, Amazon RDS promuove la replica di dimensioni maggiori. Se due o più repliche Aurora condividono la stessa priorità e le stesse dimensioni, Amazon RDS promuove una replica arbitraria 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 tuo Aurora Serverless v2 cluster o il tuo provisioning contiene istanze reader in altre istanze, AZs Aurora utilizza il meccanismo di failover per promuovere una di quelle istanze reader a 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 con un SQL database My esterno o un'istanza RDS My SQL DB. Per ulteriori informazioni, consulta Replica tra Aurora e SQL My o tra Aurora e un altro cluster Aurora DB (replica di log binari).
Disponibilità elevata con Amazon RDS Proxy
Con RDS Proxy, puoi creare applicazioni in grado di tollerare in modo trasparente gli errori del database senza dover scrivere un codice complesso per la gestione degli errori. Il proxy instrada automaticamente il traffico verso una nuova istanza database preservando le connessioni alle applicazioni. Inoltre, ignora le cache del Domain Name System (DNS) per ridurre i tempi di failover fino al 66% per i database Aurora Multi-AZ. Per ulteriori informazioni, consulta Utilizzo di Amazon RDS Proxy per Aurora.
