Comment puis-je résoudre les problèmes de latence des réplicas avec Amazon RDS for MySQL ?

Dernière mise à jour : 21/08/2020

Comment trouver la cause de la latence des réplicas au cours de l'utilisation d'Amazon Relational Database Service (Amazon RDS) for MySQL?

Brève description

Amazon RDS for MySQL utilise une réplication asynchrone et parfois la réplique n'est pas capable de suivre l'instance principale de la base de données. Cela peut entraîner un retard de réplication.

Lorsque vous utilisez un réplica en lecture Amazon RDS for MySQL avec la réplication basée sur la position du fichier journal binaire, vous pouvez surveiller le retard de réplication dans Amazon CloudWatch en consultant la métrique ReplicaLag d'Amazon RDS. La métrique ReplicaLag indique la valeur du champ Seconds_Behind_Master de la commande SHOW SLAVE STATUS.

Seconds_Behind_Master montre la différence entre l'horodatage actuel sur l'instance de la base de données réplica et l'horodatage original enregistré sur l'instance principale de base de données pour l'événement qui est traité sur l'instance de la base de données réplica.

La réplication MySQL fonctionne selon trois threads : Binlog Dump, IO_THREAD et SQL_THREAD. Pour plus d'informations sur le fonctionnement de ces threads, reportez-vous à la documentation MySQL sur les informations d'implémentation de la réplication. Si un retard est constaté au niveau de la réplication, identifiez d'abord s'il est dû au réplica IO_THREAD ou SQL_THREAD. Vous pourrez ensuite identifier la cause racine de la latence.

Résolution

Pour identifier le thread de réplication qui présente une latence, référez-vous aux exemples suivants :

1.    Exécutez la commande MASTER STATUS sur l’instance de base de données principale et examinez le résultat :

mysql> SHOW MASTER STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.066552|      521 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Remarque : dans cet exemple, l'instance de base de données principale envoie les journaux binaires vers le fichier mysql-bin.066552.

2.    Exécutez la commande SHOW SLAVE STATUS sur l'instance de base de données réplica et examinez le résultat :

Exemple A :

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Master_Log_File: mysql-bin.066548
Read_Master_Log_Pos: 10050480
Relay_Master_Log_File: mysql-bin.066548
Exec_Master_Log_Pos: 10050300
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Dans l'exemple A, Master_Log_File: mysql-bin.066548 indique que le réplica IO_THREAD lit le fichier journal binaire mysql-bin.066548. C’est parce que l’instance de base de données principale envoie les journaux binaires vers le fichier mysql-bin.066552. Ce résultat montre que le réplica IO_THREAD accuse un retard de 4 journaux. Toutefois, le fichier Relay_Master_Log_File correspond à mysql-bin.066548, ce qui indique que le réplica SQL_THREAD lit le même fichier que IO_THREAD. Cela signifie que le réplica SQL_THREAD suit le rythme, mais que le réplica IO_THREAD est en retard.

Exemple de sortie B :

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Master_Log_File: mysql-bin.066552
Read_Master_Log_Pos: 430
Relay_Master_Log_File: mysql-bin.066530
Exec_Master_Log_Pos: 50360
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

L'exemple de sortie B montre que le fichier journal principal est mysql-bin-changelog.066552. Il s'agit également du paramètre de fichier du statut principal, ce qui implique qu'IO_THREAD suit l'instance de base de données principale. Dans l’exemple du réplica, le thread SQL exécute Relay_Master_Log_File: mysql-bin-changelog.066530. Cela signifie que SQL_THREAD accuse un retard de 12journaux binaires.

Normalement, IO_THREAD ne cause pas de délais de réplication importants, car IO_THREAD lit uniquement les journaux binaires à partir de l’instance principale. Cependant, la connectivité et la latence du réseau peuvent affecter la vitesse de lecture entre les serveurs. Il est possible que le réplica IO_THREAD soit lent, dû à une utilisation élevée de la bande passante.

Si le réplica SQL_THREAD est la source des latences de réplication, voici les causes probables :

  • 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 de données principale
  • Journaux binaires synchronisés sur le disque de l'instance de base de données du réplica
  • Binlog_format du réplica est défini sur ROW
  • Latence au niveau de la création du réplica

Requêtes lentes sur l'instance principale

Les requêtes lentes exécutées sur l'instance de base de données principale, nécessitant le même temps d'exécution sur l'instance de base de données du réplica, peuvent augmenter la latence de seconds_behind_master. Par exemple, si vous avez démarré une modification sur l'instance de base de données principale et qu'il faut une heure pour l'exécuter, au moment où cette modification commence à être exécutée sur le réplica, le décalage est d'une heure. Étant donné que le changement peut également prendre une heure sur le réplica, le décalage total sera d'environ deux heures au moment où cette modification sera terminée. Il s'agit d'un délai attendu, mais vous pouvez toujours le réduire en surveillant le journal de requêtes lentes sur l'instance principale. Vous pouvez aussi identifier les instructions lentes afin de réduire le temps de latence. Une fois identifiées, vous pouvez les transformer en instructions plus courtes ou en transactions. Pour plus d'informations, reportez-vous à la section Accès aux journaux de requêtes lentes et générales MySQL.

Taille de classe ou espace de stockage de l'instance de base de données insuffisant

Si la classe d'instance de réplica ou la configuration de stockage est plus petite que sur l’instance de base de principale, le réplica est limité et incapable de suivre les modifications apportées à l’instance principale. Assurez-vous que le type d'instance de base de données du réplica est identique ou supérieur à celui de l'instance de base de données principale. Pour que la réplication fonctionne correctement, chaque réplica en lecture nécessite la même quantité de ressources de calcul et de stockage que l'instance de base de données source. Pour plus d'informations, consultez la section Classes d'instance de base de données.

Requêtes parallèles exécutées sur l'instance de base de données principale

Si vous exécutez des requêtes en parallèle sur le réplica principal, elles sont validées par ordre séquentiel sur le réplica. Cela est dû au fait que la réplication MySQL est à thread unique (SQL_THREAD), par défaut. Si un volume élevé d'écritures sur l'instance de base de données source se produit en parallèle, les écritures sur le réplica en lecture sont sérialisées à l'aide d'un seul SQL_THREAD. Cela peut provoquer une latence entre l'instance de base de données source et le réplica en lecture.

La réplication multithread (en parallèle) est disponible pour MySQL 5.6, MySQL 5.7 et les versions ultérieures. Pour plus d'informations sur la réplication multithread, reportez-vous à la documentation MySQL sur les options et variables de journalisation binaire.

La réplication multithread peut entraîner des ruptures lors de la réplication. Par exemple, la réplication multithread n'est pas la meilleure pratique pour ignorer les erreurs de réplication, car il est difficile d'identifier les transactions ignorées. Cela peut entraîner des ruptures de données entre les instances de base de données principale et de réplica.

Journaux binaires synchronisés sur le disque de l'instance de base de données du réplica

Si vous activez les sauvegardes automatiques sur le réplica, il faudra peut-être redoubler d’efforts pour synchroniser les journaux binaires sur le disque du réplica. La valeur par défaut du paramètre sync_binlog est définie sur 1. Si vous définissez cette valeur sur 0, la synchronisation du journal binaire sur le disque par le serveur MySQL est désactivée. Au lieu de se connecter au disque, le système d'exploitation vide parfois les journaux binaires sur le disque.

Si vous désactivez la synchronisation des journaux binaires, cela peut réduire la charge de performances requise pour synchroniser les journaux binaires sur le disque à chaque validation. Toutefois, en cas de panne de courant ou de panne du système d'exploitation, il se peut que certaines des validations ne soient pas synchronisées avec les journaux binaires. Cela peut affecter les capacités de restauration à un moment donné (PITR). Pour plus d'informations, consultez la documentation MySQL sur sync_binlog.

Binlog_format du réplica est défini sur ROW

Si vous définissez le binlog_format du réplica sur ROW et que la table sur laquelle les mises à jour sont effectuées ne contient pas de clé primaire, alors par défaut slave-rows-search-algorithms=TABLE_SCAN,INDEX_SCAN est exécuté sur chaque ligne modifiée de la clé primaire. Ce paramètre effectue également une analyse complète de la table sur le réplica. Dans ce cas, une solution à court terme consiste à remplacer l'algorithme de recherche par INDEX_SCAN, HASH_SCAN pour réduire la surcharge liée à l'analyse complète de la table. Pour une solution permanente, ajoutez une clé primaire explicite à chaque table.

Pour plus d'informations sur le paramètre slave-rows-search-algorithms, reportez-vous à la documentation MySQL sur slave-rows-search-algorithms.

Latence au niveau de la création du réplica

Amazon RDS crée un réplica en lecture d’une instance principale MySQL en prenant un instantané de bases de données de l’instance principale. Ensuite, Amazon RDS restaure l'instantané afin de créer une nouvelle instance de base de données (réplica) et établit la réplication entre les deux.

Amazon RDS prend du temps pour créer de nouveaux réplicas en lecture. Lorsque la réplication est établie, une latence est observée pendant toute la durée nécessaire à la création d'une sauvegarde du serveur principal. Pour minimiser cette latence, créez une sauvegarde manuelle avant de demander la création du réplica. L'instantané pris par le processus de création de réplica est une sauvegarde incrémentielle, plus rapide.

Lorsqu'un réplica en lecture est restauré à partir d'un instantané, il n'attendra pas que toutes les données soient transférées depuis Amazon Simple Storage Service (Amazon S3) vers le volume Amazon Elastic Block Store (Amazon EBS) associé à l'instance de base de données de réplica. L'instance de base de données de réplica est disponible pour effectuer les opérations de base de données. Le nouveau volume créé à partir d'un instantané Amazon EBS existant est chargé en arrière-plan (chargement différé).

La latence des réplicas Amazon RDS for MySQL (volumes basés sur EBS) peut augmenter dès le début, car le processus de chargement peut influencer les performances de la réplication. Pour plus d'informations, consultez la section Initialisation des volumes Amazon EBS.

Envisagez d'activer la fonction de préparation du cache InnoDB, qui peut offrir des gains de performances en enregistrant l'état actuel du pool de mémoires tampons de l'instance de base de données principale, puis en rechargeant le pool de mémoires tampons sur le réplica en lecture restauré. Pour plus d'informations sur la préparation du cache InnoDB, consultez MySQL sur Amazon RDS.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?