Pourquoi ma connexion est-elle redirigée vers l'instance de lecteur lorsque j'essaie de me connecter à mon terminal Amazon Aurora Writer ?

Brève description

Lorsque vous essayez de vous connecter à votre point de terminaison de cluster Aurora ou à votre point de terminaison Writer, il se peut que votre application se connecte à l'instance de lecteur à la place. Cela se produit lorsque le terminal et ses adresses IP mappées sont mis en cache du côté de l'application cliente.

Les points de terminaison du cluster Aurora pointent toujours vers l'instance Aurora Writer. En cas de basculement, le point de terminaison du cluster Aurora pointe vers la nouvelle instance d'écriture. Si vous utilisez le point de terminaison du cluster, vos connexions de lecture/écriture sont automatiquement redirigées vers une réplique Aurora lors du basculement. Cette instance de réplica est promue au rang de principale.

Ainsi, lors du basculement, l'adresse IP sous-jacente de votre instance Aurora peut changer et la valeur mise en cache risque de ne plus être en service.

Un client qui tente de se connecter à une base de données à l'aide d'un nom DNS doit convertir ce nom DNS en adresse IP en interrogeant un serveur DNS. Le client met ensuite les réponses en cache. Par protocole, les réponses DNS indiquent la durée de vie (TTL), qui régit la durée pendant laquelle le client doit mettre l'enregistrement en cache. Les zones DNS Aurora utilisent un TTL court de cinq secondes. Mais de nombreux systèmes implémentent des caches clients avec des paramètres différents, ce qui peut allonger le TTL.

Si un client essaie de se connecter au cluster alors que les modifications apportées aux enregistrements DNS n'ont pas été propagées, il reçoit une ancienne adresse. Cela amène le client à se connecter à l'instance principale précédente, qui est désormais l'instance de lecteur.

Ainsi, la mise en cache des données DNS pendant une période prolongée peut entraîner des échecs de connexion.

Le client ne reçoit plus le trafic TCP de la base de données après le lancement du basculement. Au lieu de cela, c'est au client de prendre une pause. Cette séparation stricte de la base de données principale d'origine en cas de basculement signifie que le client constate un comportement similaire lors des basculements planifiés et imprévus.

Solution

Vérifiez si vous vous connectez à l'instance Writer ou à une réplique Aurora.

Pour déterminer si votre client se connecte à l'instance Writer ou à une réplique Aurora, utilisez la variable @ @innodb_read_only :

mysql> select @@innodb_read_only;

La valeur 0 signifie que vous êtes connecté à l'instance Writer.

Exécutez cette requête pour déterminer à quel serveur vous êtes connecté et si ce serveur est un rédacteur ou un lecteur :

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)

Résoudre les problèmes liés à plusieurs instances de lecteurs dans un cluster

Les points de terminaison du lecteur Aurora sont des entrées DNS CNAME. Si un cluster possède plusieurs instances de lecteurs, lorsque vous résolvez le point de terminaison du lecteur, vous obtenez une adresse IP d'instance choisie de manière circulaire. En effet, le point de terminaison du lecteur contient toutes les répliques d'Aurora et fournit un équilibrage de charge circulaire basé sur le DNS pour les nouvelles connexions.

Assurez-vous de continuer à résoudre le point de terminaison sans mettre le DNS en cache pour obtenir une adresse IP d'instance différente pour chaque résolution. Si vous ne résolvez le point de terminaison qu'une seule fois et que vous conservez la connexion dans votre pool, chaque requête relative à cette connexion est dirigée vers la même instance. Si vous mettez le DNS en cache, vous recevez la même adresse IP d'instance chaque fois que vous résolvez le point de terminaison.

Suivez les bonnes pratiques

• Assurez-vous que les configurations de votre réseau et de vos clients n'augmentent pas davantage le TTL du cache DNS. Si vous utilisez une forme quelconque de regroupement de connexions ou de multiplexage, il se peut que vous deviez supprimer ou réduire la durée de vie de toutes les informations DNS mises en cache. Si votre application cliente met en cache les données DNS de vos instances de base de données, définissez une valeur TTL inférieure à 30 secondes.
• Utilisez le proxy Amazon Relational Database Service (Amazon RDS) pour gérer les connexions. Pour plus d'informations, consultez Utilisation du proxy Amazon RDS.
• Passez en revue les meilleures pratiques en matière d'utilisation de pilotes intelligents.
• Utilisez un équilibreur de charge basé sur TCP tel qu'Elastic Load Balancing ou HA/Proxy.

---

Informations connexes

Types de points de terminaison Aurora

Mise en cache DNS

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