Implementazioni cluster di database multi-AZ

Una distribuzione cluster DB Multi-AZ è una modalità di distribuzione semisincrona e ad alta disponibilità di Amazon RDS con due istanze DB 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 MariaDB o MySQL con tempi di inattività ridotti.

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 DB supportati per cluster DB Multi-AZ in Amazon RDS.

Disponibilità di classi di istanze per cluster DB Multi-AZ

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

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

Panoramica dei 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.

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 API DescribedBClusters per trovare queste informazioni.

Gestione di un cluster DB Multi-AZ con AWS Management Console

Puoi gestire un cluster di database Multi-AZ con la console.

L'immagine seguente mostra un cluster di database Multi-AZ nella console.

Le azioni disponibili nel menu Actions (Operazioni) dipende dal fatto che siano selezionati o meno il cluster di database Multi-AZ o un'istanza database nel cluster.

Scegliere il cluster di database Multi-AZ per visualizzare i dettagli del cluster ed eseguire operazioni a livello di cluster.

Scegliere un'istanza database in un cluster di database Multi-AZ per visualizzare i dettagli dell'istanza database ed eseguire operazioni a livello di istanza database.

Utilizzo di 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.

Aggiornamento della versione del motore di un cluster database multi-AZ

Amazon RDS fornisce versioni più recenti di ogni motore di database supportato in modo da poter mantenere aggiornato il cluster DB Multi-AZ. Quando Amazon RDS supporta una nuova versione di un motore di database, puoi scegliere come e quando aggiornare i cluster database multi-AZ.

Esistono due tipi di upgrade che puoi eseguire:

Attualmente, Amazon RDS supporta gli aggiornamenti delle versioni principali solo per i cluster DB RDS per PostgreSQL Multi-AZ. Amazon RDS supporta aggiornamenti di versione minori per tutti i motori DB che supportano cluster DB Multi-AZ.

Amazon RDS non aggiorna automaticamente le repliche di lettura del cluster database multi-AZ. Per gli aggiornamenti di versioni minori, devi prima aggiornare manualmente tutte le repliche di lettura e quindi aggiornare il cluster. In caso contrario, l'aggiornamento viene bloccato. Quando esegui l'aggiornamento della versione principale di un cluster, lo stato di tutte le repliche di lettura cambia in Terminato. Devi eliminare e ricreare le repliche di lettura al completamento dell'aggiornamento. Per ulteriori informazioni, consulta Monitoraggio della replica di lettura.

Il processo di aggiornamento della versione del motore di un cluster database multi-AZ è identico al processo di aggiornamento di una versione del motore di istanze database. Per istruzioni, consulta Aggiornamento della versione del motore di un'istanza database. L'unica differenza è che quando si usa AWS Command Line Interface (AWS CLI), si usa il modify-db-clustercomando e si specifica il --db-cluster-identifier parametro (insieme al --allow-major-version-upgrade parametro).

Per ulteriori informazioni sugli aggiornamenti delle versioni principali e secondarie, consultate la seguente documentazione per il motore DB:

Utilizzo di Server proxy per RDS con cluster di database Multi-AZ

Puoi usare Amazon RDS Proxy per creare un proxy per i tuoi cluster DB Multi-AZ. Utilizzando RDS Proxy, le tue applicazioni possono raggruppare e condividere connessioni al database per migliorare la loro capacità di scalabilità. Ogni proxy esegue il multiplexing delle connessioni, noto anche come riutilizzo delle connessioni. Con il multiplexing, Server proxy per RDS esegue tutte le operazioni per una transazione utilizzando una connessione al database sottostante, RDS Proxy può anche ridurre i tempi di inattività per un aggiornamento di versione minore di un cluster DB Multi-AZ a un secondo o meno. Per ulteriori informazioni sui vantaggi di Server proxy per RDS, consulta Utilizzo di Amazon RDS Proxy .

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.

Configurazione della replica esterna da cluster DB Multi-AZ

Puoi configurare la replica tra un cluster DB Multi-AZ e un database esterno ad Amazon RDS. Consulta le istruzioni nelle sezioni seguenti a seconda del motore DB in uso.

RDS for MySQL

Per configurare la replica esterna per un cluster DB RDS for MySQL Multi-AZ, è necessario conservare i file di log binari sulle istanze DB all'interno del cluster per un periodo sufficiente a garantire che le modifiche vengano applicate alla replica prima che Amazon RDS elimini il file binlog. A tale scopo, configura la conservazione dei log binari chiamando la stored procedure e specificando il parametro. mysql.rds_set_configuration binlog retention hours Per ulteriori informazioni, consulta binlog retention hours.

Il valore predefinito per binlog retention hours èNULL, il che significa che i log binari non vengono conservati (0 ore). Se si desidera configurare la replica esterna per un cluster DB Multi-AZ, è necessario impostare il parametro su un valore diverso da. NULL

È possibile configurare la conservazione dei log binari solo dall'istanza Writer DB del cluster DB Multi-AZ e l'impostazione viene propagata a tutte le istanze DB Reader in modo asincrono.

Inoltre, consigliamo vivamente di abilitare la replica basata su GTID sulla replica esterna. Quindi, se una delle istanze DB si guasta, puoi riprendere la replica da un'altra istanza DB integra all'interno del cluster. Per ulteriori informazioni, vedere Replication with Global Transaction Identifiers nella documentazione di MySQL.

RDS per PostgreSQL.

Per configurare la replica esterna per un cluster DB RDS for PostgreSQL Multi-AZ, è necessario abilitare la replica logica. Per istruzioni, consulta Utilizzo della replica logica di PostgreSQL con cluster database multi-AZ.

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 RDSAmazon 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

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:

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 del flusso limita le transazioni di scrittura sull'istanza DB di Writer per cercare di contenere il ritardo della 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 del flusso, imposta 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)

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

Processo di failover per cluster di database Multi-AZ

Se si verifica un’interruzione pianificata o non pianificata dell'istanza database di scrittura in un cluster di database Multi-AZ, Amazon RDS esegue automaticamente il failover su un’istanza database di lettura in un'altra zona di disponibilità. Il tempo necessario per il completamento del failover varia in base all'attività del database e ad altre condizioni presenti quando l'istanza database in scrittura diventa non disponibile. Il failover richiede in genere meno di 35 secondi. Il failover viene completato quando entrambe le istanze database del lettore hanno applicato transazioni in sospeso dallo scrittore in errore. Al termine del failover, la modifica della console RDS in base alla nuova zona di disponibilità può richiedere ulteriore tempo.

Failover automatici

Amazon RDS gestisce i failover automaticamente, in modo da consentirti di riprendere le operazioni database il più rapidamente possibile, senza alcun intervento amministrativo. Per eseguire il failover, l'istanza database del scrittore passa automaticamente a un'istanza database del lettore.

Failing manuale su un cluster di database Multi-AZ

Se si esegue manualmente il failover di un cluster DB Multi-AZ, RDS interrompe innanzitutto l'istanza DB principale. Quindi, il sistema di monitoraggio interno rileva che l'istanza DB principale non è integra e promuove un'istanza DB di replica leggibile. Il failover richiede in genere meno di 35 secondi.

È possibile eseguire il failover di un cluster DB Multi-AZ manualmente utilizzando l'API AWS Management Console AWS CLI, the o RDS.

aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster

Determinare se un cluster di database Multi-AZ ha effettuate un fail over

Per determinare se il cluster database Multi-AZ è soggetto a failover, è possibile eseguire le seguenti operazioni:

Per informazioni su come rispondere ai failover, ridurre i tempi di ripristino e su altre best practice per Amazon RDS, consulta Le migliori pratiche per Amazon RDS.

Impostazione di JVM TTL per le ricerche del nome DNS

Il meccanismo di failover modifica automaticamente il record Domain Name System (DNS) dell'istanza database in modo da fare riferimento all'istanza database di lettura. Di conseguenza, sarà necessario ristabilire le connessioni esistenti alla propria istanza database. In un ambiente Java Virtual Machine (JVM), a causa del funzionamento del meccanismo di memorizzazione nella cache DNS Java, potrebbe essere necessario riconfigurare le impostazioni JVM.

La JVM memorizza nella cache le ricerche del nome DNS. Quando la JVM risolve un nome host in un indirizzo IP, memorizza l'indirizzo IP nella cache per un periodo di tempo specificato, noto come (TTL). time-to-live

Poiché AWS le risorse utilizzano voci di nomi DNS che cambiano occasionalmente, si consiglia di configurare la JVM con un valore TTL non superiore a 60 secondi. Questo garantisce che quando l'indirizzo IP di una risorsa cambia, l'applicazione può ricevere e utilizzare il nuovo indirizzo IP della risorsa richiedendo il DNS.

In alcune configurazioni Java, il TTL predefinito di JVM è impostato in modo da non aggiornare mai le voci DNS finché JVM non viene riavviato. Pertanto, se l'indirizzo IP di una AWS risorsa cambia mentre l'applicazione è ancora in esecuzione, non può utilizzare tale risorsa finché non si riavvia manualmente la JVM e le informazioni IP memorizzate nella cache non vengono aggiornate. In questo caso, è fondamentale impostare il valore TTL della JVM in modo che aggiorni periodicamente le informazioni IP memorizzate nella cache.

Per modificare la TTL della JVM, imposta il valore della proprietà networkaddress.cache.ttl. Utilizza uno dei seguenti metodi, a seconda delle esigenze:

Istantanee del cluster DB Multi-AZ

Amazon RDS crea e salva backup automatici del cluster DB Multi-AZ durante la finestra di backup configurata. RDS crea un'istantanea del volume di storage del cluster DB, eseguendo il backup dell'intero cluster e non solo delle singole istanze.

Puoi anche eseguire backup manuali del tuo cluster DB Multi-AZ. Per backup a lungo termine, valuta la possibilità di esportare i dati degli snapshot su Amazon S3. Per ulteriori informazioni, consulta Creazione di uno snapshot di un cluster di database Multi-AZ.

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

In alternativa, puoi ripristinare uno snapshot del cluster DB Multi-AZ su una distribuzione Single-AZ o su un'istanza DB Multi-AZ. Per istruzioni, consultare Ripristino di uno snapshot di cluster database multi-AZ a un'istanza database.