Dans la partie I, nous avons présenté un cadre de haute disponibilité (HA) pour l'hébergement MySQL et discuté de divers composants et de leurs fonctionnalités. Maintenant, dans la partie II, nous discuterons des détails de la réplication semi-synchrone MySQL et des paramètres de configuration associés qui nous aident à assurer la redondance et la cohérence des données dans notre configuration HA. Assurez-vous de revenir à la partie III où nous passerons en revue divers scénarios d'échec qui pourraient survenir et la façon dont le cadre répond et récupère de ces conditions.
Qu'est-ce que la réplication semi-synchrone MySQL ?
En termes simples, dans une configuration de réplication semi-synchrone MySQL, le maître valide les transactions vers le moteur de stockage uniquement après avoir reçu l'accusé de réception d'au moins un des esclaves. Les esclaves fourniraient un accusé de réception uniquement après la réception et la copie des événements dans les journaux de relais et également vidés sur le disque. Cela garantit que pour toutes les transactions validées et renvoyées au client, les données existent sur au moins 2 nœuds. Le terme « semi » dans semi-synchrone (réplication) est dû au fait que le maître valide les transactions une fois que les événements sont reçus et vidés dans le journal de relais, mais pas nécessairement dans les fichiers de données sur l'esclave. Cela contraste avec la réplication entièrement synchrone, où la transaction aurait été validée à la fois sur l'esclave et le maître avant que la session ne revienne au client.
La réplication semi-synchrone, qui est nativement disponible dans MySQL, aide le cadre HA à assurer la cohérence et la redondance des données pour les transactions validées. En cas de défaillance du maître, toutes les transactions validées sur le maître auraient été répliquées sur au moins un des esclaves (sauvegardées dans les journaux de relais). Par conséquent, le basculement vers cet esclave serait sans perte car l'esclave est à jour (une fois que les journaux de relais de l'esclave sont entièrement vidés).
Réplication et paramètres associés semi-synchrones
Discutons de certains des paramètres MySQL clés utilisés pour assurer un comportement optimal pour une haute disponibilité et la cohérence des données dans notre cadre.
Gestion de la vitesse d'exécution des esclaves
La première considération est de gérer le comportement « semi » de la réplication semi-synchrone qui garantit uniquement que les données ont été reçues et vidées dans les journaux de relais par le thread d'E/S du esclave, mais pas nécessairement validé par le thread SQL. Par défaut, le thread SQL d'un esclave MySQL est monothread et ne pourra pas suivre le rythme du maître qui est multithread. L'impact évident de ceci est qu'en cas de défaillance du maître, l'esclave ne sera pas à jour car son thread SQL traite toujours les événements dans le journal de relais. Cela retardera le processus de basculement car notre infrastructure s'attend à ce que l'esclave soit entièrement à jour avant de pouvoir être promu. Cela est nécessaire pour préserver la cohérence des données. Pour résoudre ce problème, nous activons les esclaves multithreads avec l'option slave_parallel_workers pour définir le nombre de threads SQL parallèles pour traiter les événements dans les journaux de relais.
De plus, nous configurons les paramètres ci-dessous qui garantissent que l'esclave n'entre pas dans un état dans lequel le maître n'était pas :
- esclave-parallèle-type =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Cela nous donne une plus grande cohérence des données. Avec ces paramètres, nous serons en mesure d'obtenir une meilleure parallélisation et une meilleure vitesse sur l'esclave, mais s'il y a trop de threads parallèles, la surcharge impliquée dans la coordination entre les threads augmentera également et peut malheureusement annuler les avantages.
Une autre configuration que nous pouvons utiliser pour augmenter l'efficacité de l'exécution parallèle sur les esclaves consiste à régler binlog_group_commit_sync_delay sur le maître. En définissant cela sur le maître, les entrées de journal binaires sur le maître et donc les entrées de journal de relais sur l'esclave auront des lots de transactions qui peuvent être traitées en parallèle par les threads SQL. Ceci est expliqué en détail dans le blog de J-F Gagné où il qualifie ce comportement de "ralentir le maître pour accélérer l'esclave" .
Si vous gérez vos déploiements MySQL via la console ScaleGrid, vous avez la possibilité de surveiller en permanence et de recevoir des alertes en temps réel sur le décalage de réplication des esclaves. Il vous permet également d'ajuster dynamiquement les paramètres ci-dessus pour vous assurer que les esclaves travaillent main dans la main avec le maître, minimisant ainsi votre temps impliqué dans un processus de basculement.
Explication du cadre de haute disponibilité MySQL – Partie IICliquez pour tweeter
Options de réplication semi-synchrone importantes
La réplication semi-synchrone MySQL, de par sa conception, peut revenir en mode asynchrone en fonction des paramètres de délai d'accusé de réception de l'esclave ou en fonction du nombre d'esclaves à capacité semi-synchrone disponibles à tout moment. Le mode asynchrone, par définition, ne garantit pas que les transactions validées sont répliquées sur l'esclave et, par conséquent, une perte du maître entraînerait la perte des données qui n'ont pas été répliquées. La conception par défaut du framework ScaleGrid HA est d'éviter de retomber en mode asynchrone. Passons en revue les configurations qui influencent ce comportement.
-
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 la configuration maître-esclave à 3 nœuds, nous définissons 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 d'un esclave avant de repasser en mode asynchrone. Nous l'avons défini sur une valeur de délai d'attente relativement élevée afin qu'il n'y ait pas de retour en mode asynchrone.
Puisque nous fonctionnons avec 2 esclaves et que le rpl_semi_sync_master_wait_for_slave_count est défini sur 1, nous avons remarqué qu'au moins un des esclaves reconnaît dans un délai raisonnable et le maître ne bascule pas en mode asynchrone lors d'interruptions temporaires du réseau.
-
rpl_semi_sync_master_wait_no_slave
Cela contrôle si le maître attend que la période de temporisation configurée par rpl_semi_sync_master_timeout expire, même si le nombre d'esclaves tombe en dessous du nombre d'esclaves configurés par rpl_semi_sync_master_wait_for_slave_count pendant la période de temporisation. Nous conservons la valeur par défaut de ON afin que le maître ne retombe pas en réplication asynchrone.
Impact de la perte de tous les esclaves semi-synchrones
Comme nous l'avons vu plus haut, notre framework empêche le maître de passer en réplication asynchrone si tous les esclaves tombent en panne ou deviennent inaccessibles depuis le maître. L'impact direct de ceci est que les écritures sont bloquées sur le maître, ce qui a un impact sur la disponibilité du service. Ceci est essentiellement tel que décrit par le théorème CAP sur les limites de tout système distribué. Le théorème stipule qu'en présence d'une partition réseau, nous devrons choisir soit la disponibilité, soit la cohérence, mais pas les deux. La partition réseau, dans ce cas, peut être considérée comme des esclaves MySQL déconnectés du maître car ils sont soit en panne, soit inaccessibles.
Notre objectif de cohérence est de garantir que pour toutes les transactions validées, les données sont disponibles sur au moins 2 nœuds. Par conséquent, dans de tels cas, le framework ScaleGrid HA privilégie la cohérence plutôt que la disponibilité. Les écritures supplémentaires ne seront pas acceptées par les clients, bien que le maître MySQL serve toujours les demandes de lecture. Il s'agit d'une décision de conception consciente que nous avons prise comme comportement par défaut qui est, bien sûr, configurable en fonction des exigences de l'application.
Assurez-vous de vous abonner au blog ScaleGrid afin de ne pas manquer la partie III où nous discuterons d'autres scénarios d'échec et des capacités de récupération du framework MySQL HA . Restez à l'écoute !!
