Perché ricevo un errore di sola lettura dopo il failover di un cluster di database Aurora compatibile con MySQL?

Breve descrizione

Quando un cluster database Aurora compatibile con MySQL subisce un failover Multi-AZ, gli endpoint del cluster si aggiornano automaticamente. Il vecchio writer si riavvia e viene impostato in modalità di sola lettura, quindi Aurora promuove una replica esistente a writer. Gli endpoint riflettono questo cambiamento e indicano i nuovi ruoli di writer e reader.

Potresti ricevere un messaggio di errore di sola lettura quando utilizzi il ruolo di reader per eseguire una delle seguenti operazioni attraverso un nodo esistente:

• Operazione DDL (Data Definition Language)
• Operazione DML (Data Manipulation Language)
• Operazione DCL (Data Control Language)

Risoluzione

Determina se il ruolo è di sola lettura

Per verificare se il ruolo è di sola lettura, utilizza la variabile innodb_read_only.

Esempio di output:

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

Utilizza l'endpoint del writer del cluster

Il ruolo di un'istanza database in un cluster Aurora MySQL può cambiare. È consigliabile utilizzare l'endpoint del writer del cluster per avere la certezza di puntare sempre verso l'ultimo writer. Se utilizzi un endpoint dell'istanza database o un indirizzo IP diretto, potresti non sapere che si verifica un failover. Quando ti riconnetti allo stesso host, ricevi un errore di sola lettura e non puoi eseguire modifiche DDL o DML.

Evita un caching DNS eccessivo

Se non utilizzi uno driver smart, dipendi dagli aggiornamenti e dalla propagazione dei record DNS dopo un evento di failover. Le zone DNS di Aurora MySQL utilizzano un time-to-live (TTL) breve di 5 secondi. Le configurazioni di rete e client non devono aumentare il TTL. Il caching DNS avviene su più livelli di un'architettura, ad esempio il sistema operativo, il livello di rete o il container dell'applicazione. Se il caching DNS è involontariamente di più di 5 secondi, potresti riconnetterti al vecchio writer dopo un failover.

Le Java Virtual Machine (JVM) possono eseguire un caching DNS eccessivo. Quando la JVM risolve un nome host in un indirizzo IP, l'indirizzo IP viene memorizzato nella cache per un periodo di tempo predefinito. In alcune configurazioni, il TTL predefinito della JVM aggiorna le voci DNS solo al riavvio della JVM e può causare errori di sola lettura dopo un failover. Per risolvere il problema, imposta manualmente un TTL ridotto in modo che le voci DNS si aggiornino periodicamente.

Utilizza il driver JDBC avanzato AWS

Gli endpoint del cluster di database Aurora MySQL propagano automaticamente gli aggiornamenti dei record DNS. Quando si verifica un evento nel database, potresti riscontrare un ritardo negli aggiornamenti dei record DNS. Quando ciò accade, l'applicazione gestisce l'evento.

Il driver wrapper JDBC (Java Database Connectivity) avanzato AWS utilizza la topografia del cluster di database tramite la tabella di metadati INFORMATION_SCHEMA.REPLICA_HOST_STATUS. Poiché la tabella è quasi in tempo reale, il driver wrapper JDBC avanzato AWS indirizza le connessioni al ruolo appropriato. Inoltre, bilancia il carico tra le repliche esistenti. Utilizza il modello proxy in Java per implementare il wrapper JDBC avanzato AWS. Devi aggiungere i driver nativi di Aurora MySQL come dipendenze. Per ulteriori informazioni, consulta Proxy pattern in Java (Modello proxy in Java) sul sito web Baeldung. Puoi scaricare il wrapper JDBC avanzato AWS dal sito web GitHub.

Per ulteriori informazioni, consulta Achieve one second or less downtime with the Advanced JDBC Wrapper Driver when upgrading Amazon RDS Multi-AZ DB Clusters (Come raggiungere un tempo di inattività pari o inferiore a un secondo con il driver wrapper JDBC avanzato durante l'aggiornamento di cluster di database Amazon RDS Multi-AZ).

Nota: un caching DNS eccessivo potrebbe influire sul driver wrapper JDBC avanzato AWS. Per ulteriori informazioni, consulta Improve application availability on Amazon Aurora (Miglioramento della disponibilità delle applicazioni in Amazon Aurora).

Testa l'istanza a cui sei connesso

Se non utilizzi un driver smart, testa l'istanza dopo aver stabilito una nuova connessione. Per verificare se sei connesso all'istanza di scrittura, utilizza la variabile @@innodb_read_only. Se ricevi un valore pari a 0, sei connesso al writer.

Esempio di output:

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

Informazioni correlate

Amazon Aurora MySQL database administrator's handbook (Manuale per l'amministratore del database Amazon Aurora MySQL)

Connessioni endpoint di Amazon Aurora