¿Por qué aparece un error de solo lectura cuando se produce una conmutación por error de un clúster de base de datos compatible con Aurora MySQL?

Descripción corta

Cuando un clúster de base de datos compatible con Aurora MySQL experimenta una conmutación por error Multi-AZ, los puntos de enlace del clúster se actualizan automáticamente. El antiguo escritor se reinicia y se establece en modo de solo lectura y, a continuación, Aurora convierte una réplica existente en un escritor. Los puntos de enlace reflejan este cambio y apuntan a los nuevos roles de escritor y lector.

Es posible que recibas un mensaje de error de solo lectura cuando utilices el rol de lector para realizar una de las siguientes operaciones a través de un nodo existente:

• Operación de lenguaje de definición de datos (DDL)
• Operación de lenguaje de manipulación de datos (DML)
• Operación de lenguaje de control de datos (DCL)

Resolución

Determinar si el rol es de solo lectura

Para comprobar si el rol es de solo lectura, utiliza la variable innodb_read_only.

Resultado de ejemplo:

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

Uso del punto de enlace del escritor del clúster

El rol de una instancia de base de datos en un clúster de Aurora MySQL puede cambiar. Se recomienda utilizar el punto de enlace del escritor de clústeres para asegurarse de que siempre se apunta al último escritor. Si usas un punto de enlace de la instancia de base de datos o una dirección IP directa, es posible que no sepas que se produce una conmutación por error. Al volver conectar al mismo host, aparece un error de solo lectura y no se pueden realizar cambios de DDL o DML.

Exceso de DNS en caché

Si no utilizas un controlador inteligente, tras un evento de conmutación por error, dependerás de las actualizaciones y la propagación del registro DNS. Las zonas DNS de Aurora MySQL utilizan un tiempo de vida (TTL) corto de 5 segundos. Las configuraciones de red y cliente no deben aumentar el TTL. El almacenamiento en caché de DNS se produce en varias capas de una arquitectura, como el sistema operativo, la capa de red o el contenedor de la aplicación. Si el DNS se almacena en caché de forma no intencionada durante más de 5 segundos, es posible que te vuelvas a conectar al escritor antiguo tras una conmutación por error.

Las máquinas virtuales de Java (JVM) pueden almacenar DNS en exceso en la caché. Cuando la JVM convierte un nombre de host en una dirección IP, almacena la dirección IP en la caché durante un periodo de tiempo especificado. En algunas configuraciones, el TTL predeterminado de la JVM actualiza las entradas de DNS solo cuando la JVM se reinicia y puede provocar errores de solo lectura tras la conmutación por error. Para resolver este problema, define manualmente un TTL pequeño para que las entradas de DNS se actualicen periódicamente.

Uso del controlador JDBC avanzado de AWS

Los puntos de enlace del clúster de bases de datos de Aurora MySQL propagan automáticamente las actualizaciones de los registros DNS. Cuando se produce un evento en la base de datos, es posible que experimentes un retraso en las actualizaciones del registro DNS. Cuando esto ocurre, la aplicación gestiona el evento.

El controlador contenedor JDBC (Java Database Connectivity) avanzado de AWS utiliza la topografía del clúster de base de datos a través de la tabla de metadatos INFORMATION_SCHEMA.REPLICA_HOST_STATUS. Como la tabla está casi en tiempo real, el controlador contenedor JDBC avanzado de AWS dirige las conexiones al rol apropiado. También equilibra la carga en las réplicas existentes. Utiliza el patrón de proxy en Java para implementar el contenedor JDBC avanzado de AWS. Debes agregar los controladores nativos de Aurora MySQL como dependencias. Para obtener más información, consulta Patrón de proxy en Java en el sitio web de Baeldung. Puedes descargar el contenedor JDBC avanzado de AWS en el sitio web de GitHub.

Para obtener más información, consulta Lograr un segundo o menos de tiempo de inactividad con el controlador contenedor JDBC avanzado al actualizar los clústeres de bases de datos de Amazon RDS Multi-AZ.

Nota: El almacenamiento en caché de DNS excesivo puede afectar al controlador contenedor JDBC avanzado AWS. Para obtener más información, consulta Mejora de la disponibilidad de las aplicaciones en Amazon Aurora.

Prueba de la instancia a la que te has conectado

Si no utilizas un controlador inteligente, prueba la instancia después de establecer una nueva conexión. Para comprobar si te has conectado a la instancia del escritor, usa la variable @@innodb_read_only. Si recibes un valor de 0, significa que estás conectado al escritor.

Resultado de ejemplo:

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

Información relacionada

Manual del administrador de bases de datos de Amazon Aurora MySQL

Conexiones de puntos de enlace de Amazon Aurora