¿Por qué se redirige mi conexión a la instancia del lector cuando intento conectarme a mi punto de conexión de escritor de Amazon Aurora?

5 minutos de lectura
0

Utilizo un punto de conexión o escritor de clúster de Amazon Aurora en mi servidor de aplicaciones, pero en su lugar mi aplicación se conecta a la instancia del lector.

Descripción breve

Cuando intente conectarse a su punto de conexión del clúster de Aurora o al extremo de escritor, es posible que en su lugar la aplicación se conecte a la instancia del lector. Esto ocurre cuando el punto de conexión y sus direcciones IP mapeadas se almacenan en caché en el extremo de la aplicación cliente.

Los puntos de conexión del clúster Aurora siempre apuntan a la instancia de escritor de Aurora. Cuando se produce una conmutación por error, el punto de conexión del clúster Aurora apunta a la nueva instancia de escritura. Si utiliza el punto de conexión del clúster, durante la conmutación por error sus conexiones de lectura/escritura se redirigen automáticamente a una réplica de Aurora. Esta instancia de réplica pasa a ser primaria.

Por lo tanto, durante la conmutación por error, la dirección IP subyacente de la instancia de Aurora puede cambiar y es posible que el valor almacenado en caché ya no esté en servicio.

Un cliente que intente conectarse a una base de datos mediante un nombre DNS debe resolver ese nombre DNS en una dirección IP consultando un servidor DNS. A continuación, el cliente almacena en caché las respuestas. Por protocolo, las respuestas de DNS especifican el tiempo de vida (TTL), que determina cuánto tiempo el cliente debe almacenar en caché el registro. Las zonas DNS de Aurora utilizan un TTL corto de cinco segundos. Sin embargo, muchos sistemas implementan cachés de clientes con diferentes configuraciones, lo que puede alargar el TTL.

Si un cliente intenta conectarse al clúster cuando los cambios en el registro DNS no se han propagado, el cliente recibe una dirección antigua. Esto hace que el cliente se conecte a la instancia principal anterior, que ahora es la instancia del lector.

Por lo tanto, almacenar en caché los datos de DNS durante un tiempo prolongado puede provocar errores de conexión.

El cliente ya no recibe el tráfico TCP de la base de datos después de que se inicie la conmutación por error. En cambio, depende del cliente el tiempo de espera. Esta restricción estricta de la base de datos principal original para cualquier conmutación por error significa que el cliente ve un comportamiento similar durante las conmutaciones por error planificadas y no planificadas.

Resolución

Compruebe si se está conectando a la instancia del escritor o a una réplica de Aurora.

Para determinar si su cliente se conecta a la instancia de escritor o a una réplica de Aurora, utilice la variable @ @innodb_read_only:

mysql> select @@innodb_read_only;

Un valor de 0 significa que está conectado a la instancia del escritor.

Ejecute esta consulta para determinar a qué servidor está conectado y si ese servidor es un escritor o un lector:

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 varias instancias de lectores en un clúster

Los puntos de conexión del lector Aurora son entradas CNAME de DNS. Si un clúster tiene varias instancias de lectores, cuando resuelva el punto de conexión del lector, obtendrá una IP de instancia que se elige de forma de todos contra todos. Esto se debe a que el punto de conexión del lector contiene todas las réplicas de Aurora y proporciona un equilibrio de carga de todos contra todos basado en DNS para las nuevas conexiones.

Asegúrese de seguir resolviendo el punto de conexión sin almacenar en caché el DNS para obtener una IP de instancia diferente en cada resolución. Si resuelve el punto de conexión solo una vez y mantiene la conexión en su grupo, todas las consultas de esa conexión se enviarán a la misma instancia. Si almacena en caché el DNS, recibirá la misma IP de instancia cada vez que resuelva el punto de conexión.

Siga las prácticas recomendadas

  • Asegúrese de que las configuraciones de red y cliente no aumenten aún más el TTL de la caché de DNS. Si utiliza algún tipo de agrupación de conexiones u otro tipo de multiplexación, es posible que tenga que vaciar o reducir el tiempo de vida de la información de DNS almacenada en caché. Si la aplicación cliente almacena en caché los datos de DNS de las instancias de base de datos, establezca un valor TTL de menos de 30 segundos.
  • Utilice el proxy de Amazon Relational Database Service (Amazon RDS) para administrar las conexiones. Para obtener más información, consulte Utilizar Amazon RDS Proxy.
  • Revise las prácticas recomendadas para el uso de controladores inteligentes.
  • Utilice un equilibrador de cargas basado en TCP, como Elastic Load Balancing o HA/Proxy.

Información relacionada

Tipos de puntos de conexión de Aurora

Almacenamiento en caché DNS

¿Por qué obtuve un error de solo lectura luego de que falló un clúster de base de datos de Amazon Aurora?

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año