Implementazioni di cluster di database Multi-AZ per Amazon RDS - Amazon Relational Database Service

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à.

Implementazioni di cluster di database Multi-AZ per Amazon RDS

Un’implementazione di cluster di database Multi-AZ è una modalità di implementazione semi-sincrona a disponibilità elevata di Amazon RDS con due istanze database di replica leggibili. Un cluster DB Multi-AZ ha un'istanza DB writer e due istanze DB reader in tre zone di disponibilità separate nella stessa Regione AWS. I cluster di database multi-AZ offrono elevata disponibilità, maggiore capacità per i carichi di lavoro in lettura e minore latenza di scrittura rispetto alle implementazioni di istanze database Multi-AZ.

È possibile importare dati da un database on-premise in un cluster database multi-AZ seguendo le istruzioni riportate in Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto.

Puoi acquistare istanze database riservate per cluster database Multi-AZ. Per ulteriori informazioni, consulta Istanze database riservate per un cluster di database Multi-AZ.

Il supporto varia a seconda delle versioni specifiche di ciascun motore di database e a seconda delle Regioni AWS. Per ulteriori informazioni sulla disponibilità di versioni e regioni per Amazon RDS con cluster di database Multi-AZ, consulta Regioni e motori di database supportati per i cluster di database Multi-AZ in Amazon RDS.

Importante

I cluster di database multi-AZ non sono gli stessi dei cluster di database Aurora. Per ulteriori informazioni sull'utilizzo di cluster di database Aurora, consulta la Guida per l'utente di Amazon Aurora.

Disponibilità di classi di istanza per i cluster di database Multi-AZ

Le implementazioni di cluster di database Multi-AZ sono supportate per le seguenti classi di istanza database: db.m5d, db.m6gd, db.m6id, db.m6idn, db.r5d, db.r6gd, db.x2iedn, db.r6id, db.r6idn e db.c6gd.

Nota

Le classi di istanza c6gd sono le uniche che supportano le dimensioni dell’istanza medium.

Per maggiori informazioni sulle classi di istanza database, consulta Classi di istanze database .

Architettura cluster di database Multi-AZ

Con un cluster di database Multi-AZ, Amazon RDS replica i dati dall'istanza database di scrittore a entrambe le istanze database di lettore utilizzando le funzionalità di replica nativa del motore database. Quando viene apportata una modifica all'istanza database di scrittore, viene inviata a ciascuna istanza database di lettura.

Le implementazioni di cluster Multi-AZ utilizzano la replica semi-sincrona, che richiede la conferma da almeno un'istanza database di lettura affinché venga eseguito il commit di una modifica. Non viene richiesta la conferma dell'avvenuta esecuzione o dell'avvenuto commit degli eventi in tutte le repliche.

Le istanze database di lettore fungono da target di failover automatici e servono anche il traffico di lettura per aumentare il throughput di lettura delle applicazioni. Se si verifica un'interruzione sull'istanza database di scrittura, RDS gestisce il failover su una delle istanze database di lettura. RDS esegue questa operazione in base a quale istanza database di lettura ha il ritardo di replica più recente.

Il seguente diagramma mostra un cluster di database Multi-AZ.

Cluster di database Multi-AZ

I cluster database Multi-AZ hanno in genere una latenza di scrittura inferiore rispetto alle implementazioni di istanze database AZ multiple. Consentono inoltre l'esecuzione di carichi di lavoro di sola lettura su istanze database di lettura. La console RDS mostra la zona di disponibilità dell'istanza database di scrittore e le zone di disponibilità delle istanze database del lettore. Puoi anche utilizzare il comando describe-db-clustersCLI o l'operazione Descrivi DBClusters API per trovare queste informazioni.

Importante

Per evitare errori di replica nei cluster database multi-AZ RDS per MySQL, consigliamo vivamente di utilizzare una chiave primaria in tutte le tabelle.

Gruppi di parametri per cluster di database Multi-AZ

In un cluster di database Multi-AZ, un gruppo di parametri del cluster di database funge da container per i valori di configurazione del motore che sono applicati a ogni istanza database in un cluster di database Multi-AZ.

In un cluster di database Multi-AZ, un DB parameter group (Gruppo di parametri database) è impostato sul gruppo di parametri del database predefinito per il motore del database e la versione del motore di database. Le impostazioni del gruppo di parametri del cluster di database vengono utilizzate per tutte le istanze database nel cluster.

Per informazioni sui gruppi di parametri, consultare Utilizzo di gruppi di parametri cluster di database per cluster database Multi-AZ.

Server proxy per RDS con cluster di database Multi-AZ

Per creare un proxy per i cluster di database Multi-AZ, è possibile utilizzare Server proxy per Amazon RDS che consente alle applicazioni di creare pool delle connessioni di database e di condividerle per migliorare la capacità di dimensionamento. Ogni proxy esegue il multiplexing delle connessioni, noto anche come riutilizzo della connessione. Con il multiplexing, Server proxy per RDS esegue tutte le operazioni per una transazione utilizzando una connessione al database sottostante, Server proxy per RDS può anche ridurre il tempo di inattività dovuto a un aggiornamento di versione secondaria di un cluster di database Multi-AZ a un secondo o meno. Per ulteriori informazioni sui vantaggi di Server proxy per RDS, consulta Server proxy per Amazon RDS.

Per configurare un proxy per un cluster di database Multi-AZ, scegli Crea un RDS Proxy durante la creazione del cluster. Per istruzioni su come creare e gestire gli endpoint di Server proxy per RDS, consulta Utilizzo degli endpoint Amazon RDS Proxy.

Ritardo di replica e cluster di database Multi-AZ

Replica lag (Ritardo di replica) è la differenza di tempo tra l'ultima transazione sull'istanza database di scrittura e l'ultima transazione applicata su un'istanza database di lettura. La CloudWatch metrica Amazon ReplicaLag rappresenta questa differenza di fuso orario. Per ulteriori informazioni sulle CloudWatch metriche, consulta. Monitoraggio dei parametri di Amazon RDS con Amazon CloudWatch

Sebbene i cluster di database Multi-AZ consentano prestazioni di scrittura elevate, può comunque verificarsi un ritardo di replica a causa della natura della replica basata sul motore. Poiché qualsiasi failover deve prima risolvere il ritardo di replica prima di promuovere una nuova istanza database di scrittura, il monitoraggio e la gestione di questo ritardo di replica devono essere presi in considerazione.

Per i cluster di database Multi-AZ di RDS for MySQL, il tempo di failover dipende dal ritardo di replica di entrambe le istanze database di lettura rimanenti. Entrambe le istanze database di lettura devono applicare transazioni non applicate prima che una di esse venga promossa a nuova istanza database di scrittura.

Per i cluster di database Multi-AZ di RDS for PostgreSQL, il tempo di failover dipende dal ritardo di replica delle due istanze database di lettura rimanenti. L’istanza database di lettura con il ritardo di replica minore deve applicare transazioni non applicate prima di essere promossa a nuova istanza database di scrittura.

Per un tutorial che mostra come creare un CloudWatch allarme quando il ritardo della replica supera un determinato periodo di tempo, consulta. Tutorial: creazione di un allarme Amazon CloudWatch per il ritardo di replica del cluster di database Multi-AZ per Amazon RDS

Cause comuni del ritardo di replica

In generale, il ritardo di replica si verifica quando il carico di lavoro in scrittura è troppo alto per consentire alle istanze database di lettura di applicare le transazioni in modo efficiente. Diversi carichi di lavoro possono subire ritardi di replica temporanei o continui. Di seguito sono riportati alcuni esempi di cause comuni:

  • Alta concorrenza di scrittura o aggiornamento in batch pesante sull'istanza database di scrittura, che causano il ritardo del processo di applicazione sulle istanze database di lettura.

  • Carico di lavoro in lettura pesante che utilizza risorse su una o più istanze database di lettura. L'esecuzione di query lente o di grandi dimensioni può influire sul processo di applicazione e può causare un ritardo di replica.

  • Le transazioni che modificano grandi quantità di dati o istruzioni DDL possono talvolta causare un aumento temporaneo del ritardo di replica perché il database deve mantenere l'ordine di commit.

Mitigazione del ritardo di replica

Per i cluster di database Multi-AZ per RDS for MySQL e RDS for PostgreSQL, è possibile ridurre il ritardo di replica riducendo il carico sull'istanza database di scrittura. È inoltre possibile utilizzare il controllo di flusso per ridurre il ritardo di replica. Flow control (Controllo di flusso) funziona limitando le scritture sull'istanza database di scrittura, che garantisce che il ritardo di replica non continui a crescere senza limiti. La limitazione della scrittura viene eseguita aggiungendo un ritardo alla fine di una transazione, che riduce la velocità effettiva di scrittura sull'istanza database di scrittura. Sebbene il controllo di flusso non garantisca l'eliminazione del ritardo, può contribuire a ridurre il ritardo complessivo in molti carichi di lavoro. Le seguenti sezioni forniscono informazioni sull'utilizzo del controllo di flusso con RDS for MySQL e RDS for PostgreSQL.

Mitigazione del ritardo di replica con il controllo di flusso per RDS for MySQL

Quando utilizzi i cluster di database Multi-AZ di RDS for MySQL, il controllo di flusso viene attivato per impostazione predefinita utilizzando il parametro dinamico rpl_semi_sync_master_target_apply_lag. Questo parametro specifica il limite superiore desiderato per il ritardo di replica. Man mano che il ritardo di replica si avvicina a questo limite configurato, il controllo di flusso limita le transazioni di scrittura sull’istanza database di scrittura per tentare di mantenere il ritardo di replica al di sotto del valore specificato. In alcuni casi, il ritardo di replica può superare il limite specificato. Per impostazione predefinita, questo parametro è impostato su 120 secondi. Per disattivare il controllo di flusso, è necessario impostare questo parametro sul valore massimo di 86.400 secondi (un giorno).

Per visualizzare il ritardo corrente inserito dal controllo di flusso, mostra il parametro Rpl_semi_sync_master_flow_control_current_delay eseguendo la seguente query.

SHOW GLOBAL STATUS like '%flow_control%';

L'aspetto dell'output sarà simile al seguente.

+-------------------------------------------------+-------+ | Variable_name | Value | +-------------------------------------------------+-------+ | Rpl_semi_sync_master_flow_control_current_delay | 2010 | +-------------------------------------------------+-------+ 1 row in set (0.00 sec)
Nota

Il ritardoviene visualizzato in microsecondi.

Quando Performance Insights è attivato per un cluster di database RDS Multi-AZ di RDS for MySQL, è possibile monitorare l'evento di attesa corrispondente a un'istruzione SQL che indica che le query sono state ritardate da un controllo di flusso. Quando un ritardo è stato introdotto da un controllo di flusso, è possibile visualizzare l'evento di attesa /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond corrispondente all'istruzione SQL nel pannello di controllo di Performance Insights. Per visualizzare questi parametri, lo schema delle prestazioni deve essere attivato. Per informazioni su Performance Insights, consulta Monitoraggio del carico DB con Performance Insights su Amazon RDS.

Mitigazione del ritardo di replica con il controllo di flusso per RDS for PostgreSQL

Quando utilizzi i cluster di database Multi-AZ di RDS for PostgreSQL, il controllo di flusso viene implementato come estensione. Attiva un dipendente in background per tutte le istanze database nel cluster di database. Per impostazione predefinita, i dipendenti in background sulle istanze database di lettura comunicano il ritardo di replica corrente con il dipendente in background sull'istanza database di scrittura. Se il ritardo supera i due minuti su qualsiasi istanza database di lettura, il dipendente in background sull'istanza database di scrittura aggiunge un ritardo alla fine di una transazione. Per controllare la soglia di ritardo, utilizza il parametro flow_control.target_standby_apply_lag.

Quando un controllo di flusso limita un processo PostgreSQL, l'evento di attesa Extension in pg_stat_activity e Performance Insights lo indica. La funzione get_flow_control_stats visualizza i dettagli sull'entità del ritardo attualmente aggiunto.

Il controllo di flusso può beneficiare della maggior parte dei carichi di lavoro OLTP (Online Transaction Processing, elaborazione di transazioni online) che hanno transazioni brevi ma altamente simultanee. Se il ritardo è causato da transazioni di lunga durata, come le operazioni in batch, il controllo di flusso non fornisce un vantaggio altrettanto forte.

È possibile disattivare il controllo di flusso rimuovendo l'estensione da shared_preload_libraries e riavviare l'istanza database.

Eliminazione di snapshot di cluster di database Multi-AZ

Amazon RDS crea e salva i backup automatici del cluster di database Multi-AZ durante la finestra di backup dell’istanza database. RDS crea uno snapshot dei volumi di archiviazione del cluster di database eseguendo il backup dell’intero cluster anziché delle singole istanze.

È anche eseguire backup manuali del cluster di database Multi-AZ. Per i backup a lungo termine, si consiglia di esportare i dati degli snapshot in Amazon S3. Per ulteriori informazioni, consulta Creazione di uno snapshot di cluster di database Multi-AZ per Amazon RDS.

È possibile ripristinare un cluster di database Multi-AZ a un determinato momento, creando un nuovo cluster di database Multi-AZ. Per istruzioni, consulta Ripristino di un cluster di database Multi-AZ a un determinato momento.

È possibile ripristinare uno snapshot di cluster di database Multi-AZ a un’implementazione Single-AZ oppure a un’implementazione di istanza database Multi-AZ. Per istruzioni, consulta Ripristino di uno snapshot di cluster database multi-AZ a un'istanza database.