Perché la mia connessione viene reindirizzata all'istanza del processo di lettura quando tento di connettermi al mio endpoint del processo di scrittura di Amazon Aurora?

Breve descrizione

Quando provi a connetterti all'endpoint del cluster Aurora o all'endpoint del processo di scrittura, l'applicazione potrebbe invece connettersi all'istanza del processo di lettura. Ciò accade quando l'endpoint e i relativi indirizzi IP mappati vengono memorizzati nella cache all'estremità dell'applicazione client.

Gli endpoint del cluster Aurora puntano sempre all'istanza del processo di scrittura Aurora. Quando si verifica un failover, l'endpoint del cluster Aurora punta alla nuova istanza del processo di scrittura. Se si utilizza l'endpoint del cluster, durante il failover le connessioni di lettura/scrittura vengono reindirizzate automaticamente a una replica Aurora. Questa istanza di replica viene promossa a primaria.

Pertanto, durante il failover, l'indirizzo IP principale dell'istanza Aurora può cambiare e il valore memorizzato nella cache potrebbe non essere più in servizio.

Un client che tenta di connettersi a un database utilizzando un nome DNS deve risolvere quel nome DNS in un indirizzo IP interrogando un server DNS. Il client memorizza quindi nella cache le risposte. Per protocollo, le risposte DNS specificano il Time to Live (TTL), che regola per quanto tempo il client deve memorizzare nella cache il record. Le zone DNS Aurora utilizzano un breve TTL di cinque secondi. Ma molti sistemi implementano cache client con impostazioni diverse, il che può allungare il TTL.

Se un client tenta di connettersi al cluster quando le modifiche al record DNS non sono state propagate, il client riceve un vecchio indirizzo. Ciò fa sì che il client si connetta all'istanza primaria precedente, che ora è l'istanza del processo di lettura.

Pertanto, la memorizzazione nella cache dei dati DNS per un periodo prolungato può causare errori di connessione.

Il client non riceve più traffico TCP dal database dopo l'avvio del failover. Spetta invece al cliente il timeout. Questa rigida barriera del database primario originale in caso di failover significa che il client vede un comportamento simile durante i failover pianificati e non pianificati.

Risoluzione

Verifica se ti stai connettendo all'istanza processo di scrittura o a una replica Aurora.

Per determinare se il tuo client si sta connettendo all'istanza processo di scrittura o a una replica Aurora, usa la variabile @@innodb_read_only:

mysql> select @@innodb_read_only;

Un valore pari a 0 indica che sei connesso all'istanza processo di scrittura.

Esegui questa query per determinare a quale server sei connesso e se quel server è un processo di scrittura o lettura:

mysql> select concat("You are connected to '",server_id,"', which is a ",if(SESSION_ID='MASTER_SESSION_ID',"Writer","Reader")) as CONNECTION_STATUS from information_schema.replica_host_status where SERVER_ID in (select @@aurora_server_id);
+-----------------------------------------------------------------+
| CONNECTION_STATUS                                               |
+-----------------------------------------------------------------+
| You are connected to 'aurora-test-instance1', which is a Writer |
+-----------------------------------------------------------------+
1 row in set (0.08 sec)

Risoluzione dei problemi relativi a più istanze di processo di lettura in un cluster

Gli endpoint del processo di lettura Aurora sono voci DNS CNAME. Se un cluster ha più istanze di processo di lettura, quando si risolve il suo endpoint, si ottiene un IP di istanza scelto in stile round robin. Questo perché l'endpoint del processo di lettura contiene tutte le repliche Aurora e fornisce un bilanciamento del carico round robin basato su DNS per le nuove connessioni.

Assicurati di continuare a risolvere l'endpoint senza memorizzare nella cache il DNS per ottenere un IP di istanza diverso per ogni risoluzione. Se risolvi l'endpoint solo una volta e mantieni la connessione nel tuo pool, ogni query su quella connessione viene indirizzata alla stessa istanza. Se memorizzi il DNS nella cache, ricevi lo stesso IP di istanza ogni volta che risolvi l'endpoint.

Segui le best practice

• Assicurati che le configurazioni di rete e client non aumentino ulteriormente il TTL della cache DNS. Se utilizzi una qualsiasi forma di pool di connessioni o altro multiplexing, potresti dover cancellare o ridurre il tempo di vita per qualsiasi informazione DNS memorizzata nella cache. Se l'applicazione client memorizza nella cache i dati DNS delle istanze di database, imposta un valore TTL inferiore a 30 secondi.
• Usa il proxy Amazon Relational Database Service (Amazon RDS) per gestire le connessioni. Per ulteriori informazioni, consulta Utilizzare il proxy Amazon RDS.
• Consulta le best practice per l'utilizzo di driver intelligenti.
• Usa un sistema di bilanciamento del carico basato su TCP come Elastic Load Balancing o HA/Proxy.

---

Informazioni correlate

Tipi di endpoint Aurora

Memorizzazione nella cache DNS

Perché mi compare l'errore di sola scrittura dopo che il cluster DB di Amazon Aurora ha effettuato il failover?