¿Por qué se muestra un error de solo lectura tras una conmutación por error en un clúster de base de datos de Amazon Aurora?

Breve descripción

Cuando un clúster de base de datos de Amazon Aurora experimenta una conmutación por error de AZ múltiple, los puntos de conexión del clúster se actualizan automáticamente para reflejar las funciones recién asignadas de escritor y lector y señalarlas. El escritor anterior se reinicia y, a continuación, se pone en modo de solo lectura, mientras que una réplica existente pasa a ser el escritor en su lugar.

Si se muestra un mensaje de error de solo lectura, significa que está intentando realizar una operación de lenguaje de definición de datos (DDL), lenguaje de manipulación de datos (DML) o lenguaje de control de datos (DCL) a través de un nodo existente que desempeña la función de lector. En MySQL de Aurora, para confirmarlo, puede comprobar la variable innodb_read_only de la siguiente manera:

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

Resolución

Utilización del punto de conexión del escritor del clúster

Dado que el rol de una instancia de base de datos en un clúster de Aurora puede cambiar, se recomienda utilizar el punto de conexión del escritor del clúster para garantizar que siempre señale al escritor más reciente. Si utiliza el punto de conexión de la instancia de base de datos o una dirección IP directa, es posible que no sepa que se ha producido una conmutación por error y que se muestre un mensaje de solo lectura si vuelve a conectarse al mismo host. Esto impedirá que realice cambios de DDL/DML según lo previsto.

Exceso de DNS en caché

Si no utiliza un controlador inteligente, tras un evento de conmutación por error, dependerá de las actualizaciones y la propagación del registro DNS. Las zonas de DNS de Aurora utilizan un tiempo de vida (TTL) corto de 5 segundos, por lo que es importante que las configuraciones de la red y el cliente no aumenten aún más este tiempo. El almacenamiento en caché de DNS puede realizarse en varias capas de una arquitectura, como el sistema operativo, la capa de red y el contenedor de la aplicación. Es importante que entienda cómo está configurada cada una de estas capas. Si se produce un almacenamiento en caché de DNS no deseado más allá del TTL de 5 segundos, es posible que vuelva a conectarse al escritor anterior tras una conmutación por error.

Las máquinas virtuales de Java (JVM) pueden almacenar DNS en exceso en la caché de forma indefinida. Cuando la JVM convierte un nombre de host en una dirección IP, almacena la dirección IP en la caché durante un período de tiempo (TTL) especificado. En algunas configuraciones, el TTL predeterminado de la JVM está configurado para no actualizar nunca las entradas de DNS hasta que se reinicie la JVM. Esto puede provocar errores de solo lectura tras una conmutación por error. En este caso, es importante configurar manualmente un TTL reducido para que se realice una actualización periódicamente.

Utilización de un controlador inteligente

Los puntos de conexión del clúster de base de datos de Amazon Aurora propagan automáticamente las actualizaciones de los registros DNS, pero no de inmediato. Esto puede provocar retrasos en la respuesta a un evento que se haya producido en la base de datos, y la aplicación podría gestionar el evento. Un controlador inteligente utiliza la topografía de clúster de base de datos mediante la tabla de metadatos INFORMATION_SCHEMA.REPLICA_HOST_STATUS prácticamente en tiempo real. Esto ayuda a enrutar las conexiones al rol adecuado y a equilibrar la carga entre las réplicas existentes. MariaDB Connector/J es un ejemplo de controlador inteligente de terceros con compatibilidad nativa para MySQL de Aurora.

Nota: Incluso los controladores inteligentes pueden verse afectados por un exceso de almacenamiento de DNS en caché.

Comprobación de la instancia conectada

Como se menciona en las recomendaciones del manual de administración de conexiones de Aurora, si no se utiliza un controlador inteligente, se debería realizar una comprobación para saber a qué instancia se ha conectado cada vez que establezca una nueva conexión. Esto puede ayudarle a asegurarse de que se ha conectado a la instancia correcta. Puede comprobar si se ha conectado a la instancia del escritor o a un lector de Aurora con la variable @@innodb_read_only. En este ejemplo se muestra el valor 0, que significa que está conectado al escritor.

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

Información relacionada

Administración de conexiones de Amazon Aurora

Setting the JVM TTL for DNS name lookups

DBAs connection management handbook