Le distribuzioni su più zone di disponibilità di Amazon RDS, o implementazioni Multi-AZ, sono ideali per sostenere i carichi di lavoro di database di produzione, in quanto forniscono maggiori disponibilità e durabilità per le istanze database. Quando viene effettuato il provisioning di un'istanza database Multi-AZ, Amazon RDS crea automaticamente un'istanza database principale, replicando in modo sincrono i dati su un'istanza in standby situata in una zona di disponibilità separata. Ciascuna zona di disponibilità viene eseguita su un'infrastruttura fisica propria, distinta e indipendente ed è progettata in modo da essere altamente affidabile. In caso di guasto a un'infrastruttura, Amazon RDS esegue automaticamente un failover sull'istanza di standby (o su una replica di lettura nel caso di Amazon Aurora), in modo da riprendere le operazioni del database appena terminata la procedura di failover. Poiché l'endpoint dell'istanza database è lo stesso anche in seguito al failover, l'applicazione potrà ripristinare l'operatività sul database senza la necessità di interventi manuali a livello amministrativo.

Svariati motori di Amazon RDS consentono l'aggiunta di repliche di lettura per aumentare la scalabilità e garantire la disponibilità del database in caso di guasto della zona di disponibilità. Le repliche di lettura di Amazon RDS possono essere configurate con le relative istanze in standby in una zona di disponibilità diversa. Nel caso di Aurora, puoi scegliere di posizionare le repliche di lettura in molteplici zone di disponibilità.

Amazon Aurora estende ulteriormente i benefici Multi-AZ, grazie all'utilizzo di un layer di storage virtualizzato su SSD creato appositamente per i carichi di lavoro di database. Replica automaticamente lo storage per sei volte sulle tre zone di disponibilità. Lo storage di Amazon Aurora è caratterizzato dalla tolleranza ai guasti, ovvero è in grado di gestire in modo trasparente la perdita di un massimo di due copie di dati senza ripercussioni sulla disponibilità delle operazioni di scrittura del database e la perdita di un massimo di tre copie di dati senza ripercussioni sulla disponibilità delle operazioni di lettura. Aurora replica sempre i dati nelle tre zone di disponibilità, indipendentemente dal fatto che il database utilizzi o meno le repliche di lettura.

Conversione di un'istanza Amazon RDS a Multi-AZ (3:01)

Vantaggi

Durabilità migliorata

Le implementazioni Multi-AZ per i motori MySQL, MariaDB, Oracle e PostgreSQL utilizzano la replica sincrona fisica per mantenere i dati nell'istanza di standby aggiornati con l'istanza primaria. Le implementazioni Multi-AZ per il motore SQL Server utilizzano la replica sincrona logica per ottenere lo stesso risultato impiegando la tecnologia di mirroring nativa di SQL Server. Amazon Aurora utilizza un layer di storage virtualizzato su SSD creato appositamente per i carichi di lavoro di database. Tutti questi approcci consentono di preservare i dati nel caso di un errore dell'istanza database o di perdita di una delle zone di disponibilità.

Disponibilità migliorata

Quando un'istanza database viene eseguita come implementazione Multi-AZ, risulta migliorata anche la disponibilità del database. Se si verifica un errore nella zona di disponibilità o nell'istanza database, l'impatto sulla disponibilità sarà limitato all'intervallo di tempo necessario al completamento del failover automatico, in genere meno di un minuto per Amazon Aurora (e circa 30 secondi quando si usa MariaDB Connector/J) e da uno a due minuti per gli altri motori di database; per ulteriori informazioni, consulta le domande frequenti su RDS.

I vantaggi relativi alla disponibilità delle implementazioni Multi-AZ interessano anche gli interventi di manutenzione programmati. Nel caso di aggiornamenti del sistema, ad esempio l'applicazione di patch al sistema operativo o lo scaling delle istanze database, queste operazioni vengono applicate innanzitutto all'istanza di standby prima del failover automatico. In questo modo l'impatto sulla disponibilità è limitato nuovamente al solo tempo necessario per il completamento del failover.

Protezione delle prestazioni del database

A differenza delle implementazioni Single-AZ, l'attività di I/O non viene sospesa nell'istanza primaria durante il backup delle implementazioni Multi-AZ per i motori MySQL, MariaDB, Oracle e PostgreSQL perché il backup viene eseguito usando l'istanza di standby. È tuttavia importante sottolineare che è possibile rilevare livelli elevati di latenza durante i primi minuti di esecuzione dei backup delle implementazioni Multi-AZ.

In caso di errore dell'istanza nelle implementazioni di Amazon Aurora, Amazon RDS impiega la tecnologia RDS Multi-AZ per automatizzare il failover da 1 fino a 15 repliche di Amazon Aurora create in una qualsiasi delle tre zone di disponibilità. Se non è stato eseguito il provisioning delle repliche di Amazon Aurora, in caso di errore Amazon RDS tenterà di creare automaticamente una nuova istanza database di Amazon Aurora.

Failover automatico

Se si verifica un errore in un volume di storage nell'istanza primaria in un'implementazione Multi-AZ, Amazon RDS avvia automaticamente un processo di failover sull'istanza di standby aggiornata (o su una replica di lettura nel caso di Amazon Aurora). Rispetto a un'implementazione Single-AZ, in caso di errore in un database Single-AZ sarà necessario eseguire un'operazione di ripristino point-in-time avviata dall'utente. L'esecuzione di questa operazione può richiedere molte ore ed eventuali aggiornamenti dei dati successivi all'ora ripristinabile più recente (in genere, gli ultimi cinque minuti) non saranno disponibili.

Il failover dell'istanza database è un'operazione automatica che non richiede alcun intervento di manutenzione. Amazon RDS esegue il monitoraggio dello stato dell'istanza primaria e delle istanze di standby e avvia automaticamente il failover in risposta a svariate condizioni di errore.

Condizioni di failover

Amazon RDS riconosce gli scenari di errore più comuni delle implementazioni Multi-AZ e avvia automaticamente il ripristino, consentendoti di riprendere l'operatività del database con la massima rapidità senza alcun intervento manuale a livello amministrativo. Amazon RDS effettua un failover automaticamente nei seguenti casi:

  • Calo di disponibilità nella zona di disponibilità principale
  • Perdita di connettività di rete nell'istanza principale
  • Errore dell'unità di elaborazione nell'istanza principale
  • Errore di storage nell'istanza principale

Nota: l'esecuzione di operazioni quali il dimensionamento dell'istanza database o l'upgrade di sistema (ad esempio l'applicazione di patch al sistema operativo) su un'implementazione Multi-AZ avviene prima sull'istanza di standby per non pregiudicare la disponibilità, e solo in seguito viene effettuato il failover automatico (consulta la documentazione di Aurora per maggiori dettagli sul comportamento di aggiornamento). In questo modo l'impatto sulla disponibilità è limitato al tempo necessario per il completamento del failover. Nota: le implementazioni Multi-AZ di Amazon RDS non effettuano automaticamente il failover in caso di operazioni del database quali query che richiedono tempi di elaborazione particolarmente lunghi, blocchi critici o errori di danneggiamento del database.

Tolleranza ai guasti in più data center

Configurazione

Puoi utilizzare la Console di gestione AWS per creare facilmente nuove implementazioni Multi-AZ oppure modificare istanze Single-AZ esistenti in modo da convertirle in implementazioni Multi-AZ. Per creare una nuova implementazione Multi-AZ utilizzando la Console di gestione AWS, è sufficiente fare clic su "Yes" (Sì) in "Multi-AZ Deployment"(Implementazione Multi-AZ) durante l'avvio di un'istanza database. Per convertire un'istanza database Single-AZ esistente in un'implementazione Multi-AZ, utilizza l'opzione "Modify"(Modifica) corrispondente all'istanza database in uso nella Console di gestione AWS.

Implementazioni tra più regioni, implementazioni Multi-AZ e repliche di lettura

Le implementazioni Multi-AZ di Amazon RDS completano le repliche di lettura e le implementazioni tra più regioni. Sebbene queste tre funzionalità forniscano durabilità e disponibilità aumentate attraverso il mantenimento di copie aggiuntive dei dati, vi sono alcune differenze:

Implementazioni Multi-AZ

Implementazioni tra più regioni

Repliche di lettura

Lo scopo principale è una disponibilità elevata

Lo scopo principale è il disaster ricovery e le prestazioni locali

Lo scopo principale è la scalabilità

Diversi da Aurora: repliche sincrone; Aurora: repliche asincrone

Replica asincrona

Replica asincrona

Diversi da Aurora: solamente l'istanza primaria è attiva; Aurora: tutte le istanze sono attive

Tutte le regioni sono accessibili e possono essere utilizzate per la lettura

Tutte le repliche di lettura sono accessibili e possono essere utilizzate per lo scaling di lettura

Diversi da Aurora: backup automatici eseguiti con istanze di standby; Aurora: backup automatici eseguiti con un livello di storage condiviso

I backup automatici possono essere eseguiti in tutte le regioni

Nessun backup configurato per impostazione predefinita

Si estende sempre su almeno due zone di disponibilità all'interno di una singola regione

Tutte le regioni dispongono di un'implementazione Multi-AZ

Può trovarsi all'interno di una zona di disponibilità, più zone di disponibilità o più regioni

Diversi da Aurora: l'aggiornamento della versione del motore di database avviene nell'istanza principale; Aurora: l'aggiornamento di tutte le istanze avviene in contemporanea

Diversi da Aurora: l'aggiornamento della versione del motore di database è indipendente in tutte le regioni; Aurora: l'aggiornamento di tutte le istanze avviene in contemporanea

Diversi da Aurora: l'aggiornamento della versione del motore di database è indipendente dall'istanza di origine; Aurora: l'aggiornamento di tutte le istanze avviene in contemporanea

Failover automatico di istanze in standby (diverse da Aurora) o di repliche di lettura (Aurora) nel momento in cui si rileva un problema

Aurora consente la conversione di regioni secondarie a master

La conversione più essere manuale in caso di istanze di database autonome (diverse da Aurora) o nel caso di istanze primarie (Aurora)

Puoi combinare le implementazioni Multi-AZ con le caratteristiche di Amazon RDS per ottenere i vantaggi di entrambe le funzionalità. Ad esempio, puoi configurare un database di origine come Multi-AZ per una disponibilità elevata e creare una replica di lettura (in Single-AZ) per la scalabilità di lettura. In alternativa, puoi utilizzare il database Aurora Global Database per replicare i dati da un'implementazione Aurora Multi-AZ in altre regioni.

Con RDS per MySQL, PostgreSQL, MariaDB e Oracle, puoi anche impostare la replica di lettura come Multi-AZ, consentendo l'uso della replica di lettura come un obiettivo DR. Quando si converte la replica di lettura in un'istanza database autonoma, sarà già attivata la funzione Multi-AZ.

Ulteriori informazioni sulle caratteristiche di Amazon RDS
Ulteriori informazioni sulle caratteristiche di RDS

Esplora le caratteristiche principali di Amazon RDS. 

Ulteriori informazioni 
Registrati per creare un account AWS
Registrati per creare un account gratuito

Ottieni accesso istantaneo al piano gratuito di AWS. 

Registrati 
Inizia a lavorare con Amazon RDS nella console
Inizia subito nella console

Inizia a usare la Console di gestione RDS

Accedi