Por que minha conexão é redirecionada para a instância de leitura quando tento me conectar ao meu endpoint de gravação do Amazon Aurora?

5 minuto de leitura
0

Estou usando um endpoint de gravação/endpoint de cluster do Amazon Aurora em meu servidor de aplicativos, mas meu aplicativo se conecta à instância de leitura.

Breve descrição

Quando você tenta se conectar ao endpoint de gravação ou de cluster do Aurora, seu aplicativo pode se conectar à instância de leitura. Isso acontece quando o endpoint e seus endereços IP mapeados são armazenados em cache no lado do aplicativo cliente.

Os endpoints de cluster do Aurora sempre apontam para a instância de gravação do Aurora. Quando ocorre um failover, o endpoint de cluster do Aurora aponta para a nova instância de gravação. Se você estiver usando o endpoint de cluster, durante o failover suas conexões de leitura/gravação serão automaticamente redirecionadas para uma réplica do Aurora. Essa instância de réplica passa a ser a primária.

Por isso, durante o failover, o endereço IP subjacente da sua instância do Aurora pode mudar, e o valor em cache pode não estar mais em serviço.

Um cliente tentando se conectar a um banco de dados usando um nome DNS deve resolver esse nome DNS em um endereço IP consultando um servidor DNS. Em seguida, o cliente armazena as respostas em cache. Por protocolo, as respostas de DNS especificam o Time to Live (TTL, vida útil), que controla por quanto tempo o cliente deve armazenar o registro em cache. As zonas de DNS do Aurora usam um TTL curto de cinco segundos. No entanto, muitos sistemas implementam caches de clientes com configurações diferentes, o que pode tornar o TTL mais longo.

Se um cliente tentar se conectar ao cluster quando as alterações no registro DNS não tiverem sido propagadas, ele receberá um endereço antigo. Isso faz com que o cliente se conecte à instância primária anterior, que agora é a instância de leitura.

Portanto, armazenar em cache os dados do DNS por um período prolongado pode causar falhas na conexão.

O cliente não recebe mais tráfego TCP do banco de dados após o início do failover. Em vez disso, cabe ao cliente esgotar o tempo-limite. Essa restrição rígida do banco de dados primário original em qualquer failover significa que o cliente vê um comportamento semelhante durante failovers planejados e não planejados.

Resolução

Verifique se você está se conectando à instância de gravação ou a uma réplica do Aurora.

Para determinar se seu cliente está se conectando à instância de gravação ou a uma réplica do Aurora, use a variável @@innodb_read_only:

mysql> select @@innodb_read_only;

O valor 0 significa que você está conectado à instância de gravação.

Execute essa consulta para determinar a qual servidor você está conectado e se esse servidor é de gravação ou leitura:

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)

Solucionar problemas de várias instâncias de leitura em um cluster

Os endpoints de leitura do Aurora são entradas DNS CNAME. Se um cluster tiver várias instâncias de leitura, quando você resolve o endpoint de leitura, obtém um IP de instância escolhido de forma round-robin. Isso ocorre porque o endpoint de leitura contém todas as réplicas do Aurora e fornece balanceamento de carga round-robin baseado em DNS para novas conexões.

Continue resolvendo o endpoint sem armazenar o DNS em cache para obter um IP de instância diferente em cada resolução. Se você resolver o endpoint apenas uma vez e mantiver a conexão em seu pool, todas as consultas nessa conexão serão direcionadas para a mesma instância. Se você armazenar o DNS em cache, receberá o mesmo IP da instância sempre que resolver o endpoint.

Siga as práticas recomendadas

  • Certifique-se de que suas configurações de rede e cliente não aumentem ainda mais o TTL do cache DNS. Se você usar qualquer forma de pool de conexões ou outra multiplexação, pode ser necessário liberar ou reduzir a vida útil de qualquer informação de DNS em cache. Se seu aplicativo cliente estiver armazenando em cache os dados de DNS de suas instâncias de banco de dados, defina um valor de TTL de menos de 30 segundos.
  • Use o proxy do Amazon Relational Database Service (Amazon RDS) para gerenciar conexões. Para obter mais informações, consulte Using Amazon RDS Proxy (Uso do Amazon RDS Proxy).
  • Analise as melhores práticas para usar drivers inteligentes.
  • Use um balanceador de carga baseado em TCP, como o Elastic Load Balancing ou o HA/Proxy.

Informações relacionadas

Types of Aurora endpoints (Tipos de endpoints do Aurora)

DNS caching (Armazenamento em cache DNS)

Why did I get a read only error after an Amazon Aurora DB cluster failed over? (Por que recebi um erro somente leitura após o failover de um cluster de banco de dados do Amazon Aurora?)

AWS OFICIAL
AWS OFICIALAtualizada há um ano