Considérations sur l'intégrité des données et les performances dans la réplication semi-synchrone MySQL

La réplication semi-synchrone MySQL améliore l'intégrité des données, car lorsqu'un commit est renvoyé avec succès, on sait que les données existent à au moins deux endroits :le maître et son esclave. Dans cet article de blog, nous passons en revue certaines des configurations d'hébergement MySQL qui influencent l'intégrité des données et les performances de la réplication semi-synchrone. Nous utiliserons le moteur de stockage InnoDB et la réplication basée sur GTID dans un ensemble de répliques à 3 nœuds (maître et 2 esclaves), ce qui garantira la redondance des esclaves. Cela signifie que s'il y a des problèmes avec un esclave, nous pouvons nous rabattre sur l'autre.

Configurations applicables aux nœuds maître et esclave

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Ces configurations garantissent des paramètres de durabilité et de cohérence élevés pour les données. Autrement dit, chaque transaction validée est garantie d'être présente dans les journaux binaires et les journaux sont également vidés sur le disque. Ainsi, en cas de panne de courant ou de plantage du système d'exploitation, la cohérence des données de MySQL est toujours préservée.

Configurations sur le nœud maître.

• rpl_semi_sync_master_wait_for_slave_count :

Cette option est utilisée pour configurer le nombre d'esclaves qui doivent envoyer un accusé de réception avant qu'un maître semi-synchrone puisse valider la transaction. Dans le jeu de réplicas à 3 nœuds, nous vous recommandons de définir ce paramètre sur 1, afin d'avoir toujours l'assurance que les données sont disponibles dans au moins un esclave tout en évitant tout impact sur les performances lié à l'attente de l'accusé de réception des deux esclaves.

• rpl_semi_sync_master_timeout :

Cette option est utilisée pour configurer la durée pendant laquelle un maître semi-synchrone attend l'acquittement de l'esclave avant de repasser en mode asynchrone. Nous vous recommandons de définir ce paramètre sur un grand nombre afin qu'il n'y ait pas de retour au mode asynchrone qui va alors à l'encontre de notre objectif d'intégrité des données. Puisque nous fonctionnons avec 2 esclaves et que rpl_semi_sync_master_wait_for_slave_count est défini sur 1, nous pouvons supposer qu'au moins un des esclaves accuse réception dans un délai raisonnable, minimisant ainsi l'impact de ce paramètre sur les performances.

Configurations sur les nœuds esclaves

Dans les esclaves, il est toujours important de suivre très précisément deux positions :la position actuelle du thread SQL exécuté dans le journal de relais et la position actuelle du thread IO qui indique à quelle distance le fichier binaire maître est lu et copié sur l'esclave. Les conséquences du non maintien de ces positions sont assez évidentes. S'il y a un plantage et un redémarrage de l'esclave, le thread SQL peut commencer à traiter les transactions à partir d'un mauvais décalage ou le thread IO peut commencer à extraire des données d'une mauvaise position dans les journaux binaires maîtres. Ces deux cas entraîneront une corruption des données.

il est important d'assurer la sécurité des esclaves en cas de collision grâce aux configurations suivantes :

• relay_log_info_repository =TABLE
• relay_log_recovery =ACTIVÉ

La définition de relay_log_info_repository sur TABLE garantira que la position du thread SQL est mise à jour avec chaque validation de transaction sur l'esclave. Cependant, il est difficile de maintenir la position exacte du thread IO et de l'aligner sur le disque. En effet, la lecture du journal binaire maître et l'écriture dans le journal relais esclave ne sont pas basées sur les transactions. L'impact sur les performances est très élevé si la position du thread d'E/S doit être mise à jour et vidée sur le disque après chaque écriture dans les journaux de relais esclaves. Une solution plus élégante serait de définir relay_log_recovery =ON, auquel cas, s'il y a un redémarrage de MySQL, les journaux de relais actuels seront supposés être corrompus et seront fraîchement extraits du maître en fonction de la position du thread SQL.

Enfin, mais non des moindres, il est important de noter que la réplication semi-synchrone garantit que les données viennent d'« atteindre » l'un des esclaves avant que le maître ne valide la transaction, et ne signifie pas que les transactions sont validées sur l'esclave. Par conséquent, il sera bon de s'assurer que le thread SQL fonctionne avec de bonnes performances. Dans le cas idéal, le thread SQL va de pair avec le thread IO afin que nous puissions bénéficier de l'esclave non seulement pour recevoir les transactions, mais aussi pour les valider. Il est recommandé d'opter pour une configuration esclave multithread afin d'obtenir des performances accrues du thread SQL esclave. Les configurations importantes pour les esclaves multi-thread sont :

• slave_parallel_workers : Définissez-le sur > 1 pour activer plusieurs threads SQL esclaves. En fonction du nombre de threads écrivant sur le maître, nous pouvons décider d'un nombre optimal pour cela afin que l'esclave ne soit pas en retard.
• esclave-parallèle-type =LOGICAL_CLOCK
• slave-preserve-commit-order =1

Les configurations ci-dessus vont promettre le parallélisme dans l'esclave, tout en préservant l'ordre des transactions tel qu'il est vu sur le maître.

En résumé, en utilisant les configurations ci-dessus sur notre jeu de répliques MySQL, nous sommes en mesure de maintenir une intégrité élevée des données ainsi qu'une performance optimale.

Comme toujours, si vous avez des questions, laissez-nous un commentaire, contactez-nous à @scalegridio sur Twitter ou envoyez-nous un e-mail à l'assistance @scalegrid.io.