Amazon RDS | Implementazioni Multi-AZ

Amazon RDS Multi-AZ è disponibile per RDS per PostgreSQL, RDS per MySQL, RDS per MariaDB, RDS per SQL Server, RDS per Oracle e RDS per Db2. Amazon RDS Multi-AZ con due database standby leggibili è disponibile per RDS per PostgreSQL e RDS per MySQL. Per informazioni su come Amazon Aurora offre una disponibilità avanzata replicando automaticamente lo spazio di archiviazione in sei modi attraverso tre zone di disponibilità, consulta Amazon Aurora.

Per le implementazioni Single-AZ, Multi-AZ con un'istanza di standby e Multi-AZ con due istanze di standby leggibili, i prezzi si basano sulle ore di utilizzo dell'istanza database, calcolate a partire dall'avvio di un'istanza database fino al momento della sua interruzione o eliminazione. Le ore di utilizzo parziale dell'istanza database sono fatturate in incrementi di un secondo con una tariffa minima di 10 minuti derivante da un'operazione di modifica dello stato fatturabile quali la creazione, l'avvio o la modifica della classe di istanza database.

Per ulteriori informazioni sui prezzi per Amazon RDS Multi-AZ, consulta la pagina dei prezzi di Amazon RDS. 

Utilizza le seguenti guide e tutorial per l'utente per iniziare rapidamente a usare Amazon RDS Multi-AZ.

Guarda sessioni, webinar e altri video per approfondire Amazon RDS Multi-AZ.

Scopri gli ultimi miglioramenti di Amazon RDS Multi-AZ e scopri come utilizzarlo per i tuoi casi d'uso di Amazon RDS. 

Ottieni un tempo di inattività pari o inferiore a un secondo con ProxySQL aggiornando le implementazioni di Amazon RDS Multi-AZ con due standby leggibili

Cambio rapido con PgBouncer su implementazioni Amazon RDS Multi-AZ con due standby leggibili per PostgreSQL

Ottieni un tempo di inattività di un secondo o meno con Advanced JDBC Wrapper Driver durante l'aggiornamento dei cluster database Amazon RDS Multi-AZ

Esegui aggiornamenti di versione minori con un tempo di inattività di 1 secondo o meno con le implementazioni di Amazon RDS Proxy e Amazon RDS Multi-AZ con due standby leggibili

Consolidamento dei dati per applicazioni analitiche mediante replica logica per cluster Amazon RDS Multi-AZ

Le migliori strategie per ottenere prestazioni e disponibilità elevate su Amazon RDS per MySQL con cluster database Multi-AZ

Migliora le prestazioni delle applicazioni su Amazon RDS per istanze MySQL e MariaDB e cluster database MySQL Multi-AZ con scritture ottimizzate

Scegli l'opzione di implementazione Amazon RDS giusta: istanza Single-AZ, istanza Multi-AZ o cluster di database Multi-AZ

Configura Multi-AZ con Amazon RDS Custom per SQL Server

Implementa un cluster database Amazon RDS per PostgreSQL e MySQL Multi-AZ utilizzando i moduli Terraform

Nuova opzione di implementazione Multi-AZ Amazon RDS per MySQL e PostgreSQL: prestazioni di scrittura migliorate e failover più rapido

Quando crei o modifichi un'istanza DB per eseguirla come implementazione multi-AZ, Amazon RDS effettua automaticamente il provisioning di una replica sincrona di "standby", conservandola in una zona di disponibilità differente. Gli aggiornamenti all'istanza DB vengono replicati in modo sincrono sulla copia di standby nell'altra zona di disponibilità, mantenendo entrambe le istanze sincronizzate e proteggendo così gli aggiornamenti più recenti del database da eventuali errori dell'istanza DB.

Durante determinati tipi di finestra di manutenzione, oppure nell'eventualità di un errore dell'istanza DB o della zona di disponibilità, Amazon RDS esegue automaticamente il failover sulla copia di standby per consentire di ripristinare le operazioni di lettura e scrittura del database non appena la copia di standby viene attivata. Poiché il registro di nome dell'istanza database rimane invariato, l'applicazione potrà ripristinare l'operatività sul database senza la necessità di interventi manuali a livello amministrativo. Con le implementazioni Multi-AZ le repliche sono trasparenti. Non è necessario interagire direttamente con la copia di standby, né questa può essere utilizzata per il traffico in lettura. Per ulteriori informazioni sulle implementazioni multi-AZ, consulta la Guida per l'utente di Amazon RDS.

Le zone di disponibilità sono percorsi separati all'interno di una regione, isolati dai potenziali errori di altre zone di disponibilità. Ciascuna zona di disponibilità gestisce un'infrastruttura fisica propria, distinta e indipendente ed è progettata in modo da essere altamente affidabile. Macchinari e attrezzature facilmente soggetti a guasto, come generatori e apparecchiature di raffreddamento, non sono condivisi tra le zone di disponibilità. Inoltre, sono fisicamente separate, in modo tale che anche eventi estremi molto rari, come incendi, trombe d'aria o inondazioni, colpirebbero una sola zona di disponibilità. Le zone di disponibilità all'interno della stessa regione dispongono di connettività a latenza molto ridotta.

Quando esegui un'istanza database come implementazione Multi-AZ, l'istanza "principale" opera le attività in lettura e scrittura del database. Oltre a questa istanza, Amazon RDS ne crea e mantiene una di "standby", che è una replica aggiornata di quella principale. In caso di failover, l'istanza di standby viene "promossa". Dopo il failover, l'istanza di standby diventa infatti l'istanza principale e accetta le operazioni del database. Prima di questa promozione, non avrai alcuna interazione con la copia di standby (ad esempio operazioni in lettura). Se sei interessato a ridimensionare il traffico in lettura oltre la capacità di una singola istanza database, consulta le domande frequenti relative alle Repliche di lettura.

Il principale vantaggio dell'esecuzione di un'istanza DB come implementazione Multi-AZ è il miglioramento di durabilità e disponibilità del database. La disponibilità e la tolleranza ai guasti offerte dalle implementazioni Multi-AZ ne fanno una soluzione ideale per gli ambienti di produzione.

L'esecuzione di un'istanza DB come implementazione Multi-AZ consente di proteggere i dati nell'eventualità di un errore di un componente o di un calo della disponibilità in una zona di disponibilità. Se ad esempio si verifica un errore in un volume di storage sull'istanza primaria, Amazon RDS avvia automaticamente un failover sull'istanza di standby, dove gli aggiornamenti del database sono ancora intatti. In questo modo è possibile migliorare la durabilità dei dati delle distribuzioni standard in una singola zona di disponibilità, per le quali le operazioni di ripristino devono essere avviate manualmente e gli aggiornamenti applicati dopo l'ultimo punto di ripristino (in genere per un intervallo di tempo di cinque minuti) non sono disponibili.

Quando un'istanza DB 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 DB, le conseguenze sulla disponibilità si restringono all'intervallo di tempo necessario per il completamento del failover automatico. La distribuzione su più zone di disponibilità è vantaggiosa anche per gli interventi di manutenzione programmati.

Ad esempio le attività di I/O non vengono sospese sull'istanza primaria durante la finestra di backup, perché i backup automatici vengono eseguiti sull'istanza di standby. L'applicazione di patch o la modifica alla classe dell'istanza database vengono eseguite prima sulla copia di standby, e solo in seguito viene effettuato il failover automatico. In questo modo l'impatto sulla disponibilità è limitato solo al tempo necessario per il completamento del failover.

Un altro vantaggio implicito dell'esecuzione di un'istanza DB come implementazione Multi-AZ è che il failover è automatico e non richiede alcun intervento a livello amministrativo. Nel contesto di Amazon RDS, questo significa che non devi monitorare gli eventi relativi all'istanza DB né avviarne manualmente il ripristino (tramite le API RestoreDBInstanceToPointInTime o RestoreDBInstanceFromSnapshot) quando si verifica un errore in una zona di disponibilità o nell'istanza stessa.
 

In una distribuzione standard dell'istanza database in una zona di disponibilità singola, è possibile rilevare un aumento della latenza causata dalla replica sincrona dei dati.

Per creare un'implementazione multi-AZ di un'istanza database, è sufficiente fare clic su "Sì" per l'opzione "Implementazione multi-AZ" all'avvio di un'istanza database con la Console di gestione AWS.

In alternativa, se desideri usare le API di Amazon RDS, puoi richiamare l'API CreateDBInstance e impostare il parametro "Multi-AZ" sul valore "true". Per convertire un'istanza database standard (Single-AZ) in Multi-AZ, è necessario modificarla nella Console di gestione AWS oppure utilizzare l'API ModifyDBInstance e configurare il parametro "Multi-AZ" come "true".
 

Per i motori di database RDS per PostgreSQL, RDS per MySQL, RDS per MariaDB, RDS per SQL Server, RDS per Oracle e RDS per Db2, quando scegli di convertire un'istanza Amazon RDS da AZ singola a multi-AZ, si verificano i seguenti eventi:

• Viene acquisito uno snapshot dell'istanza primaria.
• Viene creata una nuova istanza in standby in una zona di disponibilità differente rispetto a quella dello snapshot.
• Viene configurata una replica sincrona tra l'istanza primaria e quella in standby.
  

Non è dunque previsto che si verifichi alcuna interruzione quando un'istanza viene trasformata da Single-AZ a Multi-AZ. Tuttavia, potrebbe notarsi una maggiore latenza mentre i dati sull'istanza di stand-by si allineano a quelli dell'istanza primaria.

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 archiviazione 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 implementazioni Multi-AZ avviene prima sull'istanza di standby per non pregiudicare la disponibilità e solo in seguito viene effettuato il failover automatico. In questo modo l'impatto sulla disponibilità è limitato al tempo necessario per il completamento del failover. Nota: le implementazioni di Amazon RDS Multi-AZ 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.

Sì, per informarti dell'esecuzione del failover automatico Amazon RDS creerà un evento di istanza DB. Per ottenere informazioni sugli eventi correlati all'istanza DB, fai clic sulla sezione "Events" della Console di Amazon RDS, oppure usa l'API DescribeEvents. Puoi anche usare le Notifiche di eventi di Amazon RDS per ricevere avvisi quando si verifica un determinato evento di database.

Il failover viene gestito automaticamente da Amazon RDS, consentendoti di riprendere l'operatività del database con la massima rapidità senza alcun intervento manuale a livello amministrativo. Durante l'esecuzione di un failover, Amazon RDS cambia il record di nome (CNAME) dell'istanza DB in modo che punti alla copia di standby, che diventa quindi la copia principale. Ti consigliamo di seguire le opportune best practice e di implementare tentativi multipli di connessione al database a livello di applicazione.

Un failover si definisce come l'intervallo di tempo compreso tra il rilevamento di un errore sull'istanza primaria e la ripresa delle transazioni sull'istanza di standby, e in genere viene completato in uno o due minuti. Sulla durata del failover può influire anche la presenza di un numero elevato di transazioni non confermate da recuperare; per ottenere risultati ottimali, si consiglia di usare, per le implementazioni Multi-AZ, tipi di istanza di dimensioni adeguate. AWS consiglia inoltre di impiegare volumi di capacità di IOPS assegnata con istanze multi-AZ, che consentono di ottenere prestazioni di velocità di trasmissione effettiva veloci, prevedibili e costanti.

Amazon RDS effettua automaticamente il failover senza alcun intervento manuale nel caso si verifichino determinate condizioni di errore. Amazon RDS, inoltre, offre un'opzione che consente di avviare un failover al riavvio di un'istanza. Puoi usare questa funzionalità tramite la Console di gestione AWS oppure richiamando l'API RebootDBInstance.

Con le implementazioni Multi-AZ, è sufficiente impostare il parametro "Multi-AZ" su "true". La creazione della copia di standby, la replica sincrona e il failover vengono gestiti automaticamente. Questo significa che non è possibile selezionare la zona di disponibilità in cui distribuire l'istanza di standby, né modificare il numero di copie di standby disponibili (Amazon RDS fornisce una copia di standby dedicata per ogni istanza DB principale). L'istanza di standby, inoltre, non può essere configurata in modo da accettare attività in lettura. Ulteriori informazioni sulle configurazioni Multi-AZ.

Sì. L'istanza di standby viene automaticamente assegnata in una zona di disponibilità differente della stessa Regione dell’istanza database principale.

Sì. Per conoscere il percorso dell'istanza principale, usa la Console di gestione AWS o l'API DescribeDBInstances.

Le zone di disponibilità sono state progettate in modo da connettersi tra loro in rete con una latenza minima, quando si trovano in una stessa regione. Potrebbe essere opportuno progettare la propria applicazione e organizzare le altre risorse AWS in modo che offrano ridondanza su più zone di disponibilità, consentendo una maggiore resistenza all'applicazione in caso di errore in una zona. A questo scopo è possibile utilizzare le implementazioni Multi-AZ, che soddisfano questa esigenza a livello di database senza alcun intervento manuale a livello amministrativo.

L'utilizzo delle funzionalità di backup automatico e snapshot di database è lo stesso in una distribuzione standard in una singola zona di disponibilità e in un'implementazione Multi-AZ. Se è in esecuzione un'implementazione Multi-AZ, i backup automatici e gli snapshot DB vengono effettuati sulla copia di standby, per evitare rallentamenti nelle operazioni di I/O sull'istanza principale. In ogni caso, sia nelle implementazioni Multi-AZ sia in quelle Single-AZ, durante i backup possono verificarsi incrementi della latenza nelle operazioni di I/O (di solito di alcuni minuti).

Anche le operazioni di ripristino (sia point-in-time sia da snapshot DB) vengono avviate nelle implementazioni Single-AZ e Multi-AZ nello stesso modo. Le distribuzioni di nuove istanze DB possono essere create con le API RestoreDBInstanceFromSnapshot oppure RestoreDBInstanceToPointInTime. Queste nuove implementazioni di istanze database possono essere sia standard che Multi-AZ, indipendentemente dal tipo di implementazione del backup sorgente.