Perché ho ricevuto un errore di sola lettura dopo il failover di un cluster database Amazon Aurora?

4 minuti di lettura
0

Sto utilizzando un cluster database Amazon Aurora e ricevo il seguente errore dopo un failover: "The MySQL server is running with the --read-only option so it cannot execute this statement" Come posso risolvere questo errore?

Descrizione breve

Quando un cluster database Amazon Aurora subisce un failover Multi-AZ, gli endpoint del cluster si aggiornano automaticamente per riflettere e indicare i nuovi ruoli assegnati di Writer e Reader. Il Writer precedente viene riavviato e quindi impostato in modalità di sola lettura, mentre una replica esistente viene promossa al ruolo di Writer.

Se ricevi un messaggio di errore di sola lettura, significa che stai tentando di eseguire un'operazione DDL (data definition language), DML (data manipulation language) o DCL (data control language) tramite un nodo esistente che ha il ruolo di Reader. In Aurora MySQL, puoi confermare questa operazione controllando la variabile innodb\ _read\ _only come segue:

mysql> show variables where variable_name='innodb_read_only';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_read_only | ON    |
+------------------+-------+
1 row in set (0.01 sec)

Soluzione

Utilizzo dell'endpoint Writer del cluster

Poiché il ruolo di un'istanza database in un cluster Aurora può cambiare, è consigliabile utilizzare l'endpoint Writer del cluster per assicurarsi di puntare sempre all'ultima versione del Writer. Se utilizzi l'endpoint dell'istanza database o un indirizzo IP diretto, potresti non essere al corrente del fatto che si è verificato un failover e riceverai un messaggio di sola lettura se ti riconnetterai allo stesso host. Ciò impedirà di eseguire le modifiche DDL/DML come previsto.

Caching DNS non eccessivo

Se non utilizzi un driver smart, dipendi dagli aggiornamenti e dalla propagazione dei record DNS dopo il verificarsi di un evento di failover. Le zone DNS Aurora utilizzano uno breve Time to Live (TTL) di 5 secondi, quindi è importante che le configurazioni di rete e client non aumentino ulteriormente questo valore. Il caching DNS può avvenire su più livelli di un'architettura, ad esempio il sistema operativo (OS), il livello di rete e il container dell'applicazione. È importante comprendere in che modo viene configurato ciascuno di questi livelli. Se il caching DNS non intenzionale supera il TTL di 5 secondi, è possibile che ti riconnetterai al writer precedente dopo un failover.

Le Java Virtual Machine (JVM) possono eseguire un caching DNS eccessivo, a tempo indeterminato. Quando la JVM risolve un nome host in un indirizzo IP, memorizza l'indirizzo IP nella cache per un periodo di tempo specificato (TTL). In alcune configurazioni, il TTL predefinito della JVM è impostato per non aggiornare mai le voci DNS fino al riavvio della JVM. Ciò può causare errori di sola lettura dopo un failover. In questo caso, è importante impostare manualmente un breve TTL in modo che si aggiorni periodicamente.

Uso di un driver smart

Gli endpoint del cluster database di Amazon Aurora propagano automaticamente gli aggiornamenti dei record DNS, ma il processo non avviene istantaneamente. Ciò può causare ritardi nella risposta a un evento che si è verificato nel database e l'evento potrebbe essere gestito dall'applicazione. Un driver smart utilizza la topografia del cluster database tramite la tabella di metadati INFORMATION_SCHEMA.REPLICA_HOST_STATUS, quasi in tempo reale. Ciò permette di indirizzare le connessioni al ruolo appropriato in modo più facile, inoltre aiuta a bilanciare il carico tra le repliche esistenti. MariaDB Connector/J è un esempio di driver smart di terze parti con supporto nativo per Aurora MySQL.

Nota: Anche i driver smart potrebbero essere influenzati da un caching del DNS eccessivo.

Verifica dell'istanza alla quale si è connessi

Come indicato nelle best practice del manuale di gestione della connessione Aurora, quando non si utilizza un driver smart è necessario verificare e capire a quale istanza si è connessi dopo aver stabilito una nuova connessione. Ciò permette di assicurarsi di essere connessi all'istanza corretta. Puoi verificare se la connessione all'istanza writer o a un Reader Aurora è attiva utilizzando la variabile @@innodb_read_only variable. Questo esempio mostra un valore pari a 0, indicando che si è connessi al writer.

mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
| 0                  |
+--------------------+
1 row in set (0.00 sec)

Informazioni correlate

Gestione delle connessioni Amazon Aurora

Configurazione e gestione di un'implementazione multi-AZ

Manuale per la gestione delle connessioni DBA

AWS UFFICIALE
AWS UFFICIALEAggiornata 3 anni fa