Comment puis-je résoudre l'erreur « Attente que le thread SQL esclave libère suffisamment d'espace journal du relais » dans Amazon Aurora MySQL ?

Brève description

Lorsque Aurora MySQL est un réplica de réplication de journal binaire, il exécute le thread E/S et le thread SQL de la même manière que MySQL. Le thread E/S lit les journaux binaires à partir du principal, puis les enregistre en tant que journaux de relais dans l'instance de base de données du réplica. Le thread SQL traite les événements dans les journaux de relais, puis supprime les journaux de relais lorsque les événements dans les journaux de relais sont traités.

Si le thread SQL ne traite pas les événements assez rapidement pour rattraper la vitesse à laquelle les journaux de relais sont générés, la quantité de journaux de relais augmente.

Lorsque la variable globale relay_log_space_limit est définie sur plus de 0 et que la taille totale de tous les journaux de relais atteint la limite, les nouveaux journaux de relais ne sont pas enregistrés. Jusqu'à ce que l'espace du journal relais soit à nouveau disponible, la sortie de SHOW SLAVE STATUS affiche le message « Attente que le thread SQL esclave libère suffisamment d'espace journal du relais » dans le champ Slave_IO_State.

Dans Aurora MySQL, le paramètre relay_log_space_limit est défini sur 1000000000 (953,6 Mio) et ne peut pas être modifié. Cela empêche le volume de cluster de devenir inutilement volumineux. Lorsque la taille totale de tous les journaux de relais atteint 1000000000 octets (953,6 Mio), le thread d'E/S cesse d'enregistrer les journaux de relais. Il attend que le thread SQL traite les événements et supprime les journaux existants. Slave_IO_State affiche alors le message « Attente que le thread SQL esclave libère suffisamment d'espace journal du relais ». Si le thread SQL n'est pas arrêté, les journaux de relais sont éventuellement supprimés et le thread E/S reprend l'enregistrement des nouveaux journaux de relais.

Cela signifie également qu'il existe un délai de réplication car le SQL n'est pas assez rapide pour rattraper la génération de journaux de relais par le thread d'E/S. Même si le paramètre relay_log_space_limit est modifié à une valeur plus élevée, les journaux de relais s'accumulent encore et le problème n'est pas résolu tant que le thread SQL n'aura pas rattrapé son retard.

Vous pouvez afficher l'espace journal du relais actuel, l'état du thread E/S et le statut du thread SQL dans la sortie de la commande SHOW SLAVE STATUS.

Slave_IO_State: Waiting for the slave SQL thread to free enough relay log space
Master_Log_File: mysql-bin-changelog.237029
Read_Master_Log_Pos: 55356151
Relay_Master_Log_File: mysql-bin-changelog.237023
Exec_Master_Log_Pos: 120
Relay_Log_Space: 1000002403

Master_Log_File et Read_Master_Log_Pos affichent le nom du fichier journal binaire et l'emplacement où le thread d'E/S a terminé la lecture et l'enregistrement. Relay_Master_Log_File et Exec_Master_Log_Pos affichent le nom du fichier journal binaire et la position où le thread SQL est en cours de traitement. Bien que ce que le thread SQL lit réellement sont des journaux de relais, le nom du fichier journal binaire correspondant dans l'instance de base de données principale et la position sont affichés.

Lorsque Master_Log_File est différent de Relay_Master_Log_File, le thread SQL n'est pas assez rapide. Si Master_Log_File et Relay_Master_Log_File sont identiques, le thread d'E/S peut contribuer au délai.

Les facteurs suivants peuvent entraîner des performances insuffisantes du thread SQL :

• Requêtes lentes sur l'instance de base de données principale
• Taille de classe ou espace de stockage de l'instance de base de données insuffisant
• Requêtes parallèles exécutées sur l'instance de base données principale
• Journaux binaires synchronisés sur le disque de l'instance de base de données du réplica
• Binlog_format sur l'instance de base de données du réplica est défini sur ROW

Pour plus d'informations sur la résolution de ces problèmes, consultez Comment puis-je résoudre les problèmes de latence des réplicas avec Amazon RDS for MySQL

En outre, les facteurs suivants peuvent également avoir un impact sur les performances du thread SQL :

• Une très grande longueur de liste d'historique des transactions (HLL) sur l'instance de base de données du réplica
• Opérations d'E/S moins efficaces sur l'instance de base de données du réplica
• Tables avec beaucoup d'index secondaires sur l'instance de base de données du réplica

Résolution

Tant qu'il y a des écritures qui se produisent dans votre réplica, vous n'avez pas besoin de vous soucier de l'espace journal du relais. Vous pouvez le surveiller à l'aide de la métrique Débit d'écriture dans Surveillance améliorée.

Concentrez-vous plutôt sur le dépannage des performances du réplica. Pour plus d'informations, consultez Comment puis-je résoudre les problèmes de latence des réplicas avec Amazon RDS for MySQL et Pourquoi mon réplica en lecture Amazon Aurora a-t-il pris du retard et a redémarré ?

Informations connexes

Documentation MySQL pour les options et variables du serveur de réplica