Dans cette série de blogs en trois parties, nous avons présenté un cadre de haute disponibilité (HA) pour l'hébergement MySQL dans la partie I, et discuté des détails de la réplication semi-synchrone MySQL dans la partie II. Maintenant, dans la partie III, nous examinons comment le framework gère certains des scénarios d'échec importants de MySQL et récupère pour garantir une haute disponibilité.
Scénarios d'échec MySQL
Scénario 1 – Le maître MySQL tombe en panne
- Le framework Corosync et Pacemaker détecte que le maître MySQL n'est plus disponible. Pacemaker rétrograde la ressource principale et tente de récupérer avec un redémarrage du service MySQL, si possible.
- À ce stade, en raison de la nature semi-synchrone de la réplication, toutes les transactions validées sur le maître ont été reçues par au moins un des esclaves.
- Pacemaker attend que toutes les transactions reçues soient appliquées sur les esclaves et laisse les esclaves rapporter leurs scores de promotion. Le calcul du score est fait de telle manière que le score est '0' si un esclave est complètement synchronisé avec le maître, et est un nombre négatif sinon.
- Le stimulateur cardiaque sélectionne l'esclave qui a signalé le score 0 et promeut cet esclave qui assume désormais le rôle de maître MySQL sur lequel les écritures sont autorisées.
- Après la promotion de l'esclave, l'agent de ressource déclenche un module de reroutage DNS. Le module met à jour l'entrée DNS proxy avec l'adresse IP du nouveau maître, facilitant ainsi la redirection de toutes les écritures d'application vers le nouveau maître.
- Le stimulateur cardiaque configure également les esclaves disponibles pour qu'ils commencent à se répliquer à partir de ce nouveau maître.
Ainsi, chaque fois qu'un maître MySQL tombe en panne (que ce soit en raison d'un plantage de MySQL, d'un plantage du système d'exploitation, d'un redémarrage du système, etc.), notre framework HA le détecte et promeut un esclave approprié pour reprendre le rôle du maître. Cela garantit que le système reste disponible pour les applications.
Explication du cadre de haute disponibilité #MySQL – Partie 3 :Scénarios d'échecCliquez pour tweeter
Scénario 2 - L'esclave MySQL tombe en panne
- Le framework Corosync et Pacemaker détecte que l'esclave MySQL n'est plus disponible.
- Pacemaker tente de récupérer la ressource en essayant de redémarrer MySQL sur le nœud. S'il apparaît, il est ajouté au maître actuel en tant qu'esclave et la réplication se poursuit.
- Si la récupération échoue, Pacemaker signale que cette ressource est indisponible, en fonction des alertes ou des notifications qui peuvent être générées. Si nécessaire, l'équipe d'assistance de ScaleGrid se chargera de récupérer ce nœud.
- Dans ce cas, il n'y a aucun impact sur la disponibilité des services MySQL.
Scénario 3 – Partition réseau – La connectivité réseau est interrompue entre les nœuds maître et esclave
Il s'agit d'un problème classique dans tout système distribué où chaque nœud pense que les autres nœuds sont en panne, alors qu'en réalité, seule la communication réseau entre les nœuds est interrompue. Ce scénario est plus communément appelé scénario split-brain et, s'il n'est pas géré correctement, peut conduire à ce que plusieurs nœuds prétendent être un maître MySQL, ce qui entraîne à son tour des incohérences et une corruption des données.
Prenons un exemple pour examiner comment notre cadre traite les scénarios de cerveau divisé dans le cluster. Nous supposons qu'en raison de problèmes de réseau, le cluster s'est divisé en deux groupes - maître dans un groupe et 2 esclaves dans l'autre groupe, et nous le désignerons par [(M), (S1,S2)].
- Corosync détecte que le nœud maître n'est pas en mesure de communiquer avec les nœuds esclaves, et les nœuds esclaves peuvent communiquer entre eux, mais pas avec le maître .
- Le nœud maître ne pourra valider aucune transaction car la réplication semi-synchrone attend un accusé de réception d'au moins un des esclaves avant que le maître puisse valider. Dans le même temps, Pacemaker arrête MySQL sur le nœud maître en raison d'un manque de quorum basé sur le paramètre Pacemaker "no-quorum-policy =stop". Le quorum signifie ici la majorité des nœuds, ou deux sur trois dans une configuration de cluster à 3 nœuds. Puisqu'il n'y a qu'un seul nœud maître en cours d'exécution dans cette partition du cluster, le paramètre no-quorum-policy est déclenché, entraînant l'arrêt du maître MySQL.
- Maintenant, Pacemaker sur la partition [(S1), (S2)] détecte qu'il n'y a pas de maître disponible dans le cluster et lance un processus de promotion. En supposant que S1 est à jour avec le maître (comme garanti par la réplication semi-synchrone), il est alors promu en tant que nouveau maître.
- Le trafic de l'application sera redirigé vers ce nouveau nœud MySQL maître et l'esclave S2 commencera à se répliquer à partir du nouveau maître.
Ainsi, nous constatons que le framework MySQL HA gère efficacement les scénarios de split-brain, garantissant à la fois la cohérence et la disponibilité des données en cas de rupture de la connectivité réseau entre les nœuds maître et esclave.
Ceci conclut notre série de blogs en 3 parties sur le framework MySQL High Availability (HA) utilisant la réplication semi-synchrone et la pile Corosync plus Pacemaker. Chez ScaleGrid, nous proposons un hébergement hautement disponible pour MySQL sur AWS et MySQL sur Azure qui est implémenté sur la base des concepts expliqués dans cette série de blogs. Veuillez visiter la console ScaleGrid pour un essai gratuit de nos solutions.
