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

Brève description

Amazon RDS for MySQL utilise la réplication asynchrone. Cela signifie que, parfois, le réplica n'est pas capable de suivre l'instance de base de données principale. Un retard de réplication peut alors se produire.

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, vérifiez la métrique ReplicaLag pour Amazon RDS. La métrique ReplicaLag indique la valeur du champ Seconds_Behind_Master de la commande SHOW SLAVE STATUS.

Le champ Seconds_Behind_Master affiche la différence avec l'horodatage actuel sur l'instance de base de données du réplica. L'horodatage d'origine enregistré sur l'instance de base de données principale pour l'événement en cours de traitement sur l'instance de base de données de réplica est également affiché.

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, consultez la documentation MySQL sur les threads de 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 SHOW 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 source ou 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 1 :

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 1, Master_Log_File: mysql-bin.066548 indique que le réplica IO_THREAD lit le fichier journal binaire mysql-bin.066548. L'instance de base données principale écrit les journaux binaires dans le fichier mysql-bin.066552. Ce résultat montre que le réplica IO_THREAD accuse un retard de quatre journaux binaires. 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 2 :

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 2 montre que le fichier journal de l'instance principale est mysql-bin-changelog.066552. La sortie montre que IO_THREAD se maintient avec 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 22 journaux binaires.

Normalement, IO_THREAD ne cause pas de délais de réplication importants, car ce réplica lit uniquement les journaux binaires à partir de l'instance principale ou source. Toutefois, la connectivité et la latence du réseau peuvent affecter la vitesse de lecture entre les serveurs. Le réplica IO_THREAD peut être plus lent en raison de l'utilisation élevée de bande passante.

Si le réplica SQL_THREAD est à l'origine 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 lancez une modification sur l'instance principale et que l'exécution prend une heure, 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 ces latences identifiées, vous pouvez les transformer en instructions plus courtes ou en transactions.

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

Si la configuration de stockage ou la classe d'instance de base de données du réplica est inférieure à la configuration principale, le réplica peut être limitée en raison de ressources insuffisantes. Le réplica n'est pas en mesure de suivre les modifications apportées sur 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 dans la cohérence des 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

L'activation des sauvegardes automatiques sur le réplica peut entraîner un surcoût 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.

La désactivation de la synchronisation des journaux binaires 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. Cette synchronisation peut affecter les capacités de restauration à un moment donné (PITR). Pour plus d'informations, consultez la documentation MySQL sur sync_binlog.

Binlog_format est défini sur ROW

Si vous définissez binlog_format sur ROW sur l'instance de base de données principale et qu'il manque une clé primaire dans la table source, le thread SQL effectuera une analyse complète de table sur le réplica. En effet, la valeur par défaut du paramètre slave_rows_search_algorithms est TABLE_SCAN,INDEX_SCAN. Pour résoudre ce problème à court terme, remplacez l'algorithme de recherche par INDEX_SCAN,HASH_SCAN pour réduire la surcharge liée à l'analyse complète des tables. À long terme, il est recommandé d'ajouter 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. 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.

Lorsque vous restaurez un réplica en lecture à partir d'un instantané, le réplica n'attend pas que toutes les données soient transférées depuis la source. 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 est créé à partir de chargements d'instantanés Amazon Elastic Block Store (Amazon EBS) existants en arrière-plan.

Remarque : pour les réplicas Amazon RDS for MySQL (volumes basés sur EBS), le délai de réplica peut augmenter initialement. Cela est dû au fait que l'effet de chargement différé peut influencer les performances de réplication.

Envisagez d'activer la fonction de réchauffement du cache InnoDB. Cela peut permettre des gains de performance en sauvegardant l'état actuel du groupe de mémoire tampon de l'instance de base de données principale. Ensuite, rechargez le groupe tampon sur un réplica en lecture restauré.

Informations connexes

Utilisation de la réplication MySQL dans Amazon RDS

Travailler avec les réplicas en lecture MySQL