HAQM RDS | Implementazioni Multi-AZ

HAQM 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. HAQM RDS Multi-AZ con due database standby leggibili è disponibile per RDS per PostgreSQL e RDS per MySQL. Per scoprire in che modo HAQM Aurora offra una maggiore disponibilità rendendo i dati durevoli in tre zone di disponibilità, consulta Distribuzioni Multi-AZ con Aurora Replicas.

I prezzi per le implementazioni Single-AZ, Multi-AZ con un'istanza di standby e Multi-AZ con due istanze di standby leggibili, 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 HAQM RDS Multi-AZ, consulta la pagina dei prezzi di HAQM RDS. 

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

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

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

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

Cambio rapido con PgBouncer su implementazioni HAQM 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 HAQM RDS Multi-AZ

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

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

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

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

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

Configura Multi-AZ con HAQM RDS Custom per SQL Server

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

Nuova opzione di implementazione Multi-AZ HAQM 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, HAQM 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à, HAQM 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 HAQM 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, HAQM 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, HAQM 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 HAQM 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 HAQM 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 HAQM 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.

HAQM 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. HAQM 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 HAQM 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 HAQM RDS creerà un evento di istanza DB. Per ottenere informazioni sugli eventi correlati all'istanza DB, fai clic sulla sezione "Events" della Console di HAQM RDS, oppure usa l'API DescribeEvents. Puoi anche usare le Notifiche di eventi di HAQM RDS per ricevere avvisi quando si verifica un determinato evento di database.

Il failover viene gestito automaticamente da HAQM 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, HAQM 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.

HAQM RDS effettua automaticamente il failover senza alcun intervento manuale nel caso si verifichino determinate condizioni di errore. HAQM 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 (HAQM 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.