Pourquoi ai-je reçu une erreur en lecture seule après la défaillance d'un cluster DB Amazon Aurora ?

Brève description

Lorsqu'un cluster DB Amazon Aurora subit un basculement multi-AZ, les points de terminaison du cluster sont automatiquement mis à jour pour refléter et pointer vers les rôles nouvellement attribués du scripteur et du lecteur. L'ancien scripteur est redémarré, puis défini en mode lecture seule alors qu'un réplica existant est devenu un nouveau scripteur.

Si vous recevez un message d'erreur en lecture seule, cela signifie que vous essayez d'effectuer une opération DDL (Data Definition Language), DML (Data Definition Language) ou DCL (Data Control Language) via un nœud existant qui a le rôle d’un lecteur. Dans Aurora MySQL, vous pouvez le confirmer en vérifiant la variable innodb_read_only, comme suit :

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

Résolution

Utiliser le point de terminaison du cluster scripteur

Étant donné qu’il est possible que le rôle d'une instance DB dans un cluster Aurora, il est recommandé d'utiliser le point de terminaison du cluster Scripteur pour vous assurer que vous pointez toujours vers le dernier scripteur. Si vous utilisez le point de terminaison d'instance DB ou une adresse IP directe, il se peut que vous ne soyez pas conscient qu'un basculement s'est produit et que vous obtiendrez un message en lecture seule si vous vous reconnectez au même hôte. Cela vous empêchera d'effectuer des modifications DDL/DML, comme prévu.

La mise en cache DNS ne doit pas être excessive

Si vous n'utilisez pas de pilote intelligent, vous dépendez des mises à jour d'enregistrement DNS et de la propagation après un basculement. Les zones DNS d'Aurora utilisent une durée de vie courte (TTL) de 5 secondes. Il est donc important que votre réseau et vos configurations client n'augmentent pas davantage cette situation. La mise en cache DNS peut se produire sur plusieurs couches d'une architecture, telles que le système d'exploitation (OS), la couche réseau et le conteneur d'application. Il est important de comprendre le mode de configuration de chacune de ces couches. S'il y a une mise en cache DNS non intentionnelle au-delà de la TTL de 5 secondes, il est possible de se reconnecter à l'ancien scripteur après un basculement.

Les machines virtuelles Java (JVM) peuvent mettre en cache le DNS de façon excessive, et indéfiniment. Lorsque la JVM résout un nom d'hôte en adresse IP, elle met en cache l'adresse IP pendant une période spécifiée (TTL). Sur certaines configurations, la TTL par défaut de la JVM est définie pour ne jamais actualiser les entrées DNS tant que la JVM n'est pas redémarrée. Cela peut entraîner des erreurs en lecture seule après un basculement. Dans ce cas, il est important de définir manuellement une petite TTL afin qu'elle soit actualisée de façon périodique.

Utiliser un pilote intelligent

Les points de terminaison du cluster DB Amazon Aurora propagent automatiquement les mises à jour des enregistrements DNS, mais le processus ne se produit pas instantanément. Cela peut entraîner des retards dans la réponse à un événement survenu sur la base de données, et l'événement peut être géré par l'application. Un pilote intelligent utilise la topographie de cluster DB via la table de métadonnées INFORMATION_SCHEMA.REPLICA_HOST_STATUS , qui est en quasi-temps réel. Cela permet d'acheminer les connexions vers le rôle approprié et d'équilibrer la charge entre les réplicas existants. MariaDB Connector/J est un exemple de pilote intelligent tiers qui prend en charge nativement Aurora MySQL.

Remarque : Même les pilotes intelligents peuvent être affectés par une mise en cache DNS excessive.

Testez l'instance à laquelle vous êtes connecté

Comme indiqué dans les meilleures pratiques du manuel de gestion des connexions Aurora, lorsque vous n'utilisez pas de pilote intelligent, vous devez tester et comprendre à quelle instance vous êtes connecté après avoir établi une nouvelle connexion. Cela peut vous permettre de vérifier que vous êtes connecté à la bonne instance. Vous pouvez tester si vous êtes connecté à l'instance du scripteur ou à un lecteur Aurora à l'aide de la variable @ @innodb_read_only. Cet exemple indique la valeur 0, ce qui signifie que vous êtes connecté au scripteur.

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

Informations connexes

Gestion des connexions Amazon Aurora

Définition de la TTL JVM pour les recherches de noms DNS

Manuel de gestion des connexions DBA