La réplication MySQL est un moyen très populaire de créer des couches de base de données hautement disponibles. Il est très connu, testé et robuste. Ce n'est pas sans limites, cependant. L'un d'eux, sans aucun doute, est le fait qu'il n'utilise qu'un seul "point d'entrée" - vous avez un serveur dédié dans la topologie, le maître, et c'est le seul nœud du cluster sur lequel vous pouvez émettre des écritures. Cela entraîne de graves conséquences - le maître est le seul point de défaillance et, s'il échoue, aucune écriture ne peut être exécutée par l'application. Il n'est pas surprenant que beaucoup de travail ait été consacré au développement d'outils qui réduiraient l'impact d'une perte de maître. Bien sûr, il y a des discussions sur la façon d'aborder le sujet, le basculement automatisé est-il meilleur que le basculement manuel ou non. En fin de compte, il s'agit d'une décision commerciale à prendre, mais si vous décidez de suivre la voie de l'automatisation, vous rechercherez les outils pour vous aider à y parvenir. L'un des outils, toujours très populaire, est le MHA (Master High Availability). Bien qu'il ne soit peut-être plus activement maintenu, il est toujours dans une forme stable et son énorme popularité en fait toujours l'épine dorsale des configurations de réplication MySQL hautement disponibles. Que se passerait-il, cependant, si le MHA lui-même devenait indisponible ? Peut-il devenir un point de défaillance unique ? Existe-t-il un moyen d'empêcher que cela se produise? Dans cet article de blog, nous examinerons certains des scénarios.
Tout d'abord, si vous envisagez d'utiliser MHA, assurez-vous d'utiliser la dernière version du référentiel. N'utilisez pas de versions binaires car elles ne contiennent pas tous les correctifs. L'installation est assez simple. MHA se compose de deux parties, le gestionnaire et le nœud. Node doit être déployé sur vos serveurs de base de données. Manager sera déployé sur un hôte séparé, avec node. Donc, serveurs de base de données :nœud, hôte de gestion :gestionnaire et nœud.
Il est assez facile de compiler MHA. Accédez au référentiel GitHub et clonez.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Ensuite, il s'agit de :
perl Makefile.PL
make
make installVous devrez peut-être installer certaines dépendances perl si vous n'avez pas déjà installé tous les packages requis. Dans notre cas, sur Ubuntu 16.04, nous avons dû installer ce qui suit :
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Une fois que vous avez installé MHA, vous devez le configurer. Nous n'entrerons pas dans les détails ici, il existe de nombreuses ressources sur Internet qui couvrent cette partie. Un exemple de configuration (certainement hors production) peut ressembler à ceci :
[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1La prochaine étape sera de voir si tout fonctionne et comment MHA voit la réplication :
[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr 9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr 9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).Eh bien, il s'est écrasé. En effet, MHA tente d'analyser la version de MySQL et ne s'attend pas à des traits d'union. Heureusement, le correctif est facile à trouver :https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Maintenant, nous avons MHA prêt à travailler.
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr 9 13:00:01 2019 - [info] Dead Servers:
Tue Apr 9 13:00:01 2019 - [info] Alive Servers:
Tue Apr 9 13:00:01 2019 - [info] node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306)
Tue Apr 9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Not candidate for the new Master (no_master is set)
Tue Apr 9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr 9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr 9 13:00:01 2019 - [info] binlog_do_db= , binlog_ignore_db=
Tue Apr 9 13:00:01 2019 - [info] Replication filtering check ok.
Tue Apr 9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr 9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr 9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
+--node2(10.0.0.142:3306)
+--node3(10.0.0.143:3306)
Tue Apr 9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr 9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr 9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr 9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr 9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr 9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..Comme vous pouvez le voir, MHA surveille notre topologie de réplication, vérifiant si le nœud maître est disponible ou non. Considérons quelques scénarios.
Scénario 1 - MHA en panne
Supposons que MHA n'est pas disponible. Comment cela affecte-t-il l'environnement ? De toute évidence, comme MHA est responsable de la surveillance de la santé du maître et du déclenchement du basculement, cela ne se produira pas lorsque MHA est en panne. Le plantage du maître ne sera pas détecté, le basculement ne se produira pas. Le problème est que vous ne pouvez pas vraiment exécuter plusieurs instances MHA en même temps. Techniquement, vous pouvez le faire même si MHA se plaindra du fichier de verrouillage :
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.Il démarrera cependant et tentera de surveiller l'environnement. Le problème est lorsque les deux commencent à exécuter des actions sur le cluster. Le pire des cas serait s'ils décident d'utiliser différents esclaves comme candidat maître et que le basculement sera exécuté en même temps (MHA utilise un fichier de verrouillage qui empêche les basculements ultérieurs de se produire, mais si tout se passe en même temps, et cela s'est produit dans notre tests, cette mesure de sécurité ne suffit pas).
Malheureusement, il n'existe aucun moyen intégré d'exécuter MHA de manière hautement disponible. La solution la plus simple sera d'écrire un script qui testera si MHA est en cours d'exécution et sinon, le démarrera. Un tel script devrait être exécuté à partir de cron ou écrit sous la forme d'un démon, si une granularité d'une minute de cron n'est pas suffisante.
Scénario 2 - Connexion réseau perdue du nœud du gestionnaire MHA au maître
Soyons honnêtes, c'est une très mauvaise situation. Dès que MHA ne peut pas se connecter au maître, il tentera d'effectuer un basculement. La seule exception est si Secondary_check_script est défini et qu'il a vérifié que le maître est actif. Il appartient à l'utilisateur de définir exactement les actions que MHA doit effectuer pour vérifier l'état du maître - tout dépend de l'environnement et de la configuration exacte. Un autre script très important à définir est master_ip_failover_script - il est exécuté lors du basculement et il doit être utilisé, entre autres, pour s'assurer que l'ancien maître ne s'affichera pas. Si vous avez accès à des moyens supplémentaires d'atteindre et d'arrêter le vieux maître, c'est vraiment génial. Il peut s'agir d'outils de gestion à distance comme Integrated Lights-out, il peut s'agir d'un accès à des prises de courant gérables (où vous pouvez simplement éteindre le serveur), il peut s'agir d'un accès à la CLI du fournisseur de cloud, ce qui permettra d'arrêter l'instance virtuelle . Il est de la plus haute importance d'arrêter l'ancien maître - sinon il peut arriver qu'une fois le problème de réseau résolu, vous vous retrouviez avec deux nœuds inscriptibles dans le système, ce qui est une solution parfaite pour le cerveau divisé, une condition dans laquelle les données ont divergé entre deux parties du même cluster.
Comme vous pouvez le constater, MHA peut très bien gérer le basculement MySQL. Cela nécessite certainement une configuration minutieuse et vous devrez écrire des scripts externes, qui seront utilisés pour tuer l'ancien maître et s'assurer que le cerveau divisé ne se produira pas. Cela dit, nous recommandons toujours d'utiliser des outils de gestion de basculement plus avancés comme Orchestrator ou ClusterControl, qui peuvent effectuer une analyse plus avancée de l'état de la topologie de réplication (par exemple, en utilisant des esclaves ou des proxys pour évaluer la disponibilité du maître) et qui sont et seront maintenus à l'avenir. Si vous souhaitez savoir comment ClusterControl effectue le basculement, nous aimerions vous inviter à lire cet article de blog sur le processus de basculement dans ClusterControl. Vous pouvez également découvrir comment ClusterControl interagit avec ProxySQL pour offrir un basculement fluide et transparent pour votre application. Vous pouvez toujours tester ClusterControl en le téléchargeant gratuitement.
