Dans nos blogs précédents, nous avons discuté de MHA en tant qu'outil de basculement utilisé dans les configurations maître-esclave MySQL. Le mois dernier, nous avons également blogué sur la façon de gérer MHA lorsqu'il s'est écrasé. Aujourd'hui, nous verrons les principaux problèmes que les DBA rencontrent généralement avec MHA, et comment vous pouvez les résoudre.
Une brève introduction à MHA (haute disponibilité principale)
MHA signifie (Master High Availability) est toujours d'actualité et largement utilisé aujourd'hui, en particulier dans les configurations maître-esclave basées sur la réplication non GTID. MHA effectue bien un basculement ou un commutateur principal, mais il comporte certains pièges et limitations. Une fois que MHA a effectué un basculement maître et une promotion esclave, il peut automatiquement terminer son opération de basculement de base de données en environ 30 secondes, ce qui peut être acceptable dans un environnement de production. MHA peut assurer la cohérence des données. Tout cela sans aucune dégradation des performances et sans nécessiter d'ajustements ou de modifications supplémentaires de vos déploiements ou de votre configuration existants. En dehors de cela, MHA est construit sur Perl et est une solution HA open source - il est donc relativement facile de créer des assistants ou d'étendre l'outil en fonction de la configuration souhaitée. Consultez cette présentation pour plus d'informations.
Le logiciel MHA se compose de deux composants, vous devez installer l'un des packages suivants en fonction de son rôle dans la topologie :
Nœud de gestionnaire MHA =Gestionnaire MHA (gestionnaire)/Nœud MHA (nœud de données)
Nœuds maître/esclave =nœud MHA (nœud de données)
MHA Manager est le logiciel qui gère le basculement (automatique ou manuel), prend des décisions sur le moment et l'endroit du basculement et gère la récupération de l'esclave lors de la promotion du maître candidat pour l'application des journaux de relais différentiels. Si la base de données maître meurt, MHA Manager se coordonne avec l'agent de nœud MHA car il applique les journaux de relais différentiels aux esclaves qui n'ont pas les derniers événements binlog du maître. Le logiciel MHA Node est un agent local qui surveillera votre instance MySQL et permettra au gestionnaire MHA de copier les journaux de relais des esclaves. Le scénario typique est que lorsque le maître candidat pour le basculement est actuellement en retard et que MHA le détecte, il ne dispose pas des derniers journaux de relais. Par conséquent, il attendra son mandat de MHA Manager pendant qu'il recherche le dernier esclave contenant les événements binlog et copie les événements manquants de l'esclave à l'aide de scp et les applique à lui-même.
Notez cependant que MHA n'est actuellement pas activement maintenu, mais la version actuelle elle-même est stable et peut être "assez bonne" pour la production. Vous pouvez toujours faire écho à votre voix via github pour résoudre certains problèmes ou fournir des correctifs au logiciel.
Principaux problèmes courants
Examinons maintenant les problèmes les plus courants rencontrés par un administrateur de base de données lors de l'utilisation de MHA.
L'esclave est en retard, le basculement non interactif/automatisé a échoué !
Il s'agit d'un problème typique provoquant l'abandon ou l'échec du basculement automatisé. Cela peut sembler simple, mais cela ne pointe pas vers un seul problème spécifique. Le décalage esclave peut avoir différentes raisons :
- Problèmes de disque sur le maître candidat entraînant des E/S de disque liées au traitement des lectures et des écritures. Cela peut également entraîner une corruption des données s'il n'est pas atténué.
- Les requêtes incorrectes sont répliquées, en particulier les tables qui n'ont pas de clés primaires ou d'index clusterisés.
- charge élevée du serveur.
- Serveur froid et le serveur n'a pas encore préchauffé
- Pas assez de ressources serveur. Il est possible que votre esclave ait trop peu de mémoire ou de ressources serveur lors de la réplication d'écritures ou de lectures intensives.
Ceux-ci peuvent être atténués à l'avance si vous avez une surveillance appropriée de votre base de données. Un exemple en ce qui concerne les décalages d'esclaves dans MHA est le manque de mémoire lors du vidage d'un gros fichier journal binaire. Comme exemple ci-dessous, un maître a été marqué comme mort et il doit effectuer un basculement non interactif/automatique. Cependant, comme le maître candidat était en retard et qu'il doit appliquer les journaux qui n'ont pas encore été exécutés par les threads de réplication, MHA localisera l'esclave le plus à jour ou le plus récent car il tentera de récupérer un esclave contre le plus ancien. ceux. Par conséquent, comme vous pouvez le voir ci-dessous, alors qu'il effectuait une récupération esclave, la mémoire est devenue trop faible :
[email protected]:~$ masterha_manager --conf=/etc/app1.cnf --remove_dead_master_conf --ignore_last_failover
Mon May 6 08:43:46 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon May 6 08:43:46 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Mon May 6 08:43:46 2019 - [info] Reading server configuration from /etc/app1.cnf..
…
Mon May 6 08:43:57 2019 - [info] Checking master reachability via MySQL(double check)...
Mon May 6 08:43:57 2019 - [info] ok.
Mon May 6 08:43:57 2019 - [info] Alive Servers:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306)
Mon May 6 08:43:57 2019 - [info] Alive Slaves:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Not candidate for the new Master (no_master is set)
Mon May 6 08:43:57 2019 - [info] Starting Non-GTID based failover.
….
Mon May 6 08:43:59 2019 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon May 6 08:43:59 2019 - [info]
Mon May 6 08:43:59 2019 - [info] Server 192.168.10.50 received relay logs up to: binlog.000004:106167341
Mon May 6 08:43:59 2019 - [info] Need to get diffs from the latest slave(192.168.10.70) up to: binlog.000005:240412 (using the latest slave's relay logs)
Mon May 6 08:43:59 2019 - [info] Connecting to the latest slave host 192.168.10.70, generating diff relay log files..
Mon May 6 08:43:59 2019 - [info] Executing command: apply_diff_relay_logs --command=generate_and_send --scp_user=vagrant --scp_host=192.168.10.50 --latest_mlf=binlog.000005 --latest_rmlp=240412 --target_mlf=binlog.000004 --target_rmlp=106167341 --server_id=3 --diff_file_readtolatest=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog --workdir=/tmp --timestamp=20190506084355 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --relay_dir=/var/lib/mysql --current_relay_log=relay-bin.000007
Mon May 6 08:44:00 2019 - [info]
Relay log found at /var/lib/mysql, up to relay-bin.000007
Fast relay log position search failed. Reading relay logs to find..
Reading relay-bin.000007
Binlog Checksum enabled
Master Version is 5.7.23-23-log
Binlog Checksum enabled
…
…...
Target relay log file/position found. start_file:relay-bin.000004, start_pos:106167468.
Concat binary/relay logs from relay-bin.000004 pos 106167468 to relay-bin.000007 EOF into /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog ..
Binlog Checksum enabled
Binlog Checksum enabled
Dumping binlog format description event, from position 0 to 361.. ok.
Dumping effective binlog data from /var/lib/mysql/relay-bin.000004 position 106167468 to tail(1074342689)..Out of memory!
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1090] Generating diff files failed with return code 1:0.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 08:44:00 2019 - [info]
----- Failover Report -----
app1: MySQL Master failover 192.168.10.60(192.168.10.60:3306)
Master 192.168.10.60(192.168.10.60:3306) is down!
Check MHA Manager logs at testnode20 for details.
Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.10.60(192.168.10.60:3306)
The latest slave 192.168.10.70(192.168.10.70:3306) has all relay logs for recovery.
Selected 192.168.10.50(192.168.10.50:3306) as a new master.
Recovering master server failed.
Got Error so couldn't continue failover from here.Ainsi, le basculement a échoué. Cet exemple ci-dessus montre que le nœud 192.168.10.70 contient les journaux de relais les plus à jour. Cependant, dans cet exemple de scénario, le nœud 192.168.10.70 est défini sur no_master car sa mémoire est insuffisante. Alors qu'il tente de récupérer l'esclave 192.168.10.50, il échoue !
Corrections/Résolution :
Ce scénario illustre quelque chose de très important. Un environnement de surveillance avancé doit être configuré ! Par exemple, vous pouvez exécuter un script d'arrière-plan ou un démon qui surveille l'intégrité de la réplication. Vous pouvez ajouter une entrée via une tâche cron. Par exemple, ajoutez une entrée à l'aide du script intégré masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfou créez un script d'arrière-plan qui invoque ce script et l'exécute dans un intervalle. Vous pouvez utiliser l'option report_script pour configurer une notification d'alerte au cas où elle ne serait pas conforme à vos exigences, par exemple, l'esclave est en retard d'environ 100 secondes lors d'un pic de charge élevé. Vous pouvez également utiliser des plates-formes de surveillance telles que ClusterControl pour vous envoyer des notifications en fonction des métriques que vous souhaitez surveiller.
De plus, notez que, dans l'exemple de scénario, le basculement a échoué en raison d'une erreur de mémoire insuffisante. Vous pourriez envisager de vous assurer que tous vos nœuds disposent de suffisamment de mémoire et de la bonne taille de journaux binaires, car ils auraient besoin de vider le binlog pour une phase de récupération esclave.
Esclave incohérent, l'application des différences a échoué !
En ce qui concerne le décalage esclave, puisque MHA essaiera de synchroniser les journaux de relais avec un maître candidat, assurez-vous que vos données sont synchronisées. Dites pour un exemple ci-dessous :
...
Concat succeeded.
Generating diff relay log succeeded. Saved at /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog .
scp testnode7:/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog to [email protected](22) succeeded.
Mon May 6 05:43:53 2019 - [info] Generating diff files succeeded.
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] * Phase 3.5: Master Log Apply Phase..
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon May 6 05:43:53 2019 - [info] Starting recovery on 192.168.10.50(192.168.10.50:3306)..
Mon May 6 05:43:53 2019 - [info] Generating diffs succeeded.
Mon May 6 05:43:53 2019 - [info] Waiting until all relay logs are applied.
Mon May 6 05:43:53 2019 - [info] done.
Mon May 6 05:43:53 2019 - [info] Getting slave status..
Mon May 6 05:43:53 2019 - [info] This slave(192.168.10.50)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(binlog.000010:161813650). No need to recover from Exec_Master_Log_Pos.
Mon May 6 05:43:53 2019 - [info] Connecting to the target slave host 192.168.10.50, running recover script..
Mon May 6 05:43:53 2019 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='cmon' --slave_host=192.168.10.50 --slave_ip=192.168.10.50 --slave_port=3306 --apply_files=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog --workdir=/tmp --target_version=5.7.23-23-log --timestamp=20190506054328 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon May 6 05:43:53 2019 - [info]
MySQL client version is 5.7.23. Using --binary-mode.
Applying differential binary/relay log files /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog on 192.168.10.50:3306. This may take long time...
mysqlbinlog: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
FATAL: applying log files failed with rc 1:0!
Error logs from testnode5:/tmp/relay_log_apply_for_192.168.10.50_3306_20190506054328_err.log (the last 200 lines)..
ICwgMmM5MmEwZjkzY2M5MTU3YzAxM2NkZTk4ZGQ1ODM0NDEgLCAyYzkyYTBmOTNjYzkxNTdjMDEz
….
…..
M2QxMzc5OWE1NTExOTggLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDc3NDIzNCAsIDJjOTJh
MGY5M2NmYjVhN2EwMTNkMTY3OGI0N2Q0MjMERROR 1062 (23000) at line 72: Duplicate entry '12583545' for key 'PRIMARY'
5ICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNjc4YjQ4
OTQyM2QgLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDkxNDI1MSAsIDJjOTJhMGY5M2NmYjVh
N2EwMTNkMTczN2MzOWM3MDEzICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNzM3YzNhMzcwMTUgLCAy
…
--------------
Bye
at /usr/local/bin/apply_diff_relay_logs line 554.
eval {...} called at /usr/local/bin/apply_diff_relay_logs line 514
main::main() called at /usr/local/bin/apply_diff_relay_logs line 121
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1399] Applying diffs failed with return code 22:0.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 05:43:53 2019 - [info]Un cluster incohérent est vraiment mauvais, surtout lorsque le basculement automatique est activé. Dans ce cas, le basculement ne peut pas se poursuivre car il détecte une entrée en double pour la clé primaire '12583545 '.
Corrections/Résolution :
Il y a plusieurs choses que vous pouvez faire ici pour éviter un état incohérent de votre cluster.
- Activer la réplication semi-synchrone sans perte. Consultez ce blog externe qui est un bon moyen d'apprendre pourquoi vous devriez envisager d'utiliser la semi-synchronisation dans une configuration de réplication MySQL standard.
- Exécutez constamment une somme de contrôle sur votre cluster maître-esclave. Vous pouvez utiliser pt-table-checksum et l'exécuter comme une fois par semaine ou par mois en fonction de la fréquence à laquelle votre table est mise à jour. Notez que pt-table-checksum peut augmenter le trafic de votre base de données.
- Utilisez la réplication basée sur GTID. Bien que cela n'aura pas d'incidence sur le problème en soi. Cependant, la réplication basée sur GTID vous aide à déterminer les transactions errantes, en particulier les transactions qui ont été exécutées directement sur l'esclave. Autre avantage, il est plus facile de gérer la réplication basée sur GTID lorsque vous devez changer d'hôte maître dans la réplication.
Défaillance matérielle sur le maître mais les esclaves n'ont pas encore rattrapé
L'une des nombreuses raisons pour lesquelles vous investiriez dans le basculement automatique est une défaillance matérielle sur le maître. Pour certaines configurations, il peut être plus idéal d'effectuer un basculement automatique uniquement lorsque le maître rencontre une défaillance matérielle. L'approche typique consiste à notifier en envoyant une alarme - ce qui peut signifier réveiller la personne d'astreinte au milieu de la nuit, la laisser décider quoi faire. Ce type de démarche se fait sur Github ou encore Facebook. Une panne matérielle, en particulier si le volume sur lequel résident vos binlogs et votre répertoire de données, peut perturber votre basculement, en particulier si les journaux binaires sont stockés sur ce disque défaillant. De par sa conception, MHA essaiera de sauvegarder les journaux binaires du maître en panne, mais cela ne sera pas possible si le disque est en panne. Un scénario possible peut se produire si le serveur n'est pas accessible via SSH. MHA ne peut pas enregistrer les journaux binaires et doit effectuer un basculement sans appliquer les événements de journal binaire qui existent uniquement sur le maître en panne. Cela entraînera la perte des dernières données, surtout si aucun esclave n'a rattrapé le maître.
Corrections/Résolution
Comme l'un des cas d'utilisation de MHA, il est recommandé d'utiliser la réplication semi-synchrone car elle réduit considérablement le risque d'une telle perte de données. Il est important de noter que toute écriture destinée au maître doit s'assurer que les esclaves ont reçu les derniers événements du journal binaire avant la synchronisation sur le disque. MHA peut appliquer les événements à tous les autres esclaves afin qu'ils soient cohérents les uns avec les autres.
De plus, il est également préférable d'exécuter un flux de sauvegarde de vos journaux binaires pour la reprise après sinistre en cas de défaillance du volume de disque principal. Si le serveur est toujours accessible via SSH, pointer le chemin du journal binaire vers le chemin de sauvegarde de votre journal binaire peut toujours fonctionner, de sorte que le basculement et la récupération de l'esclave peuvent toujours avancer. De cette façon, vous pouvez éviter la perte de données.
Basculement VIP (IP virtuel) provoquant un split-brain
MHA, par défaut, ne gère aucune gestion VIP. Cependant, il est facile de l'intégrer à la configuration de MHA et d'attribuer des crochets en fonction de ce que vous voulez que MHA fasse pendant le basculement. Vous pouvez configurer votre propre script et l'associer aux paramètres master_ip_failover_script ou master_ip_online_change_script. Il existe également des exemples de scripts qui se trouvent dans le répertoire
Lors d'un basculement automatique, une fois que votre script avec gestion VIP est appelé et exécuté, MHA effectuera les actions suivantes :vérifier l'état, supprimer (ou arrêter) l'ancien VIP, puis réaffecter le nouveau VIP au nouveau maître. Un exemple typique de cerveau divisé est lorsqu'un maître est identifié comme mort en raison d'un problème de réseau mais qu'en fait, les nœuds esclaves sont toujours capables de se connecter au maître. Il s'agit d'un faux positif qui entraîne souvent une incohérence des données entre les bases de données de la configuration. Les connexions client entrantes utilisant le VIP seront envoyées au nouveau maître. Alors que d'autre part, il peut y avoir des connexions locales fonctionnant sur l'ancien maître, qui est censé être mort. Les connexions locales peuvent utiliser le socket unix ou localhost pour réduire les sauts de réseau. Cela peut entraîner une dérive des données par rapport au nouveau maître et au reste de ses esclaves, car les données de l'ancien maître ne seront pas répliquées dans les esclaves.
Corrections/Résolution :
Comme indiqué précédemment, certains peuvent préférer éviter le basculement automatique à moins que les vérifications n'aient déterminé que le maître est totalement en panne (comme une panne matérielle), c'est-à-dire que même les nœuds esclaves ne sont pas en mesure de l'atteindre. L'idée est qu'un faux positif pourrait être causé par un problème de réseau entre le contrôleur de nœud MHA et le maître, donc un humain peut être mieux placé dans ce cas pour prendre une décision sur le basculement ou non.
Lorsqu'il s'agit de fausses alarmes, MHA a un paramètre appelé Secondary_check_script. La valeur placée ici peut être vos scripts personnalisés ou vous pouvez utiliser le script intégré /usr/local/bin/masterha_secondary_check qui est livré avec le package MHA Manager. Cela ajoute des vérifications supplémentaires, ce qui est en fait l'approche recommandée pour éviter les faux positifs. Dans l'exemple ci-dessous de ma propre configuration, j'utilise le script intégré masterha_secondaire_check :
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.50 --user=root --master_host=testnode6 --master_ip=192.168.10.60 --master_port=3306Dans l'exemple ci-dessus, MHA Manager effectuera une boucle basée sur la liste des nœuds esclaves (spécifiés par l'argument -s) qui vérifiera la connexion avec l'hôte maître MySQL (192.168.10.60). Notez que ces nœuds esclaves dans l'exemple peuvent être des nœuds distants externes qui peuvent établir une connexion aux nœuds de base de données au sein du cluster. Il s'agit d'une approche recommandée, en particulier pour les configurations où MHA Manager s'exécute sur un centre de données ou un réseau différent de celui des nœuds de base de données. La séquence suivante ci-dessous illustre comment il procède aux vérifications :
- Depuis l'hôte MHA -> vérifiez la connexion TCP au 1er nœud esclave (IP :192.168.10.50). Appelons cela la connexion A. Ensuite, à partir du nœud esclave, vérifie la connexion TCP au nœud maître (192.168.10.60). Appelons cette connexion B.
Si la "Connexion A" a réussi mais que la "Connexion B" a échoué dans les deux routes, masterha_secondaire_check le script se termine avec le code de retour 0 et MHA Manager décide que le maître MySQL est vraiment mort et commencera le basculement. Si la "Connexion A" a échoué, masterha_secondaire_check sort avec le code de retour 2 et MHA Manager suppose qu'il y a un problème de réseau et il ne démarre pas le basculement. Si la "Connexion B" a réussi, masterha_secondaire_check se termine avec le code de retour 3 et MHA Manager comprend que le serveur maître MySQL est réellement actif et ne démarre pas le basculement.
Un exemple de la façon dont il réagit lors du basculement basé sur le journal,
Tue May 7 05:31:57 2019 - [info] OK.
Tue May 7 05:31:57 2019 - [warning] shutdown_script is not defined.
Tue May 7 05:31:57 2019 - [info] Set master ping interval 1 seconds.
Tue May 7 05:31:57 2019 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306
Tue May 7 05:31:57 2019 - [info] Starting ping health check on 192.168.10.60(192.168.10.60:3306)..
Tue May 7 05:31:58 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:58 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:31:58 2019 - [info] Executing SSH check script: exit 0
Tue May 7 05:31:58 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Master is reachable from 192.168.10.50!
Tue May 7 05:31:58 2019 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Tue May 7 05:31:59 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:59 2019 - [warning] Connection failed 2 time(s)..
Tue May 7 05:32:00 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:00 2019 - [warning] Connection failed 3 time(s)..
Tue May 7 05:32:01 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:01 2019 - [warning] Connection failed 4 time(s)..
Tue May 7 05:32:03 2019 - [warning] HealthCheck: Got timeout on checking SSH connection to 192.168.10.60! at /usr/local/share/perl/5.26.1/MHA/HealthCheck.pm line 343.
Tue May 7 05:32:03 2019 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Tue May 7 05:32:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:04 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:32:04 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Tue May 7 05:32:04 2019 - [info] Executing SSH check script: exit 0Une autre chose à ajouter est d'attribuer une valeur au paramètre shutdown_script. Ce script est particulièrement utile si vous devez implémenter un STONITH ou une clôture de nœud appropriée afin qu'il ne ressuscite pas d'entre les morts. Cela peut éviter l'incohérence des données.
Enfin, assurez-vous que MHA Manager réside dans le même réseau local avec les nœuds du cluster, car cela réduit les risques de pannes de réseau, en particulier la connexion de MHA Manager aux nœuds de la base de données.
Éviter le SPOF dans MHA
MHA peut planter pour diverses raisons, et malheureusement, il n'y a pas de fonctionnalité intégrée pour résoudre ce problème, c'est-à-dire la haute disponibilité pour MHA. Cependant, comme nous en avons discuté dans notre blog précédent "Le gestionnaire principal de haute disponibilité (MHA) s'est écrasé ! Que dois-je faire maintenant ?", il existe un moyen d'éviter le SPOF pour MHA.
Corrections/Résolution :
Vous pouvez tirer parti de Pacemaker pour créer des nœuds actifs/en veille gérés par le gestionnaire de ressources de cluster (crm). Vous pouvez également créer un script pour vérifier l'intégrité du nœud du gestionnaire MHA. Par exemple, vous pouvez provisionner un nœud de secours qui vérifie activement le nœud du gestionnaire MHA en ssh'ing pour exécuter le script intégré masterha_check_status comme ci-dessous :
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).puis faites du node fencing si ce contrôleur est en panne. Vous pouvez également étendre l'outil MHA avec un script d'assistance qui s'exécute via une tâche cron et surveiller le processus système du script masterha_manager et le relancer si le processus est mort.
Perte de données lors du basculement
MHA s'appuie sur la réplication asynchrone traditionnelle. Bien qu'il prenne en charge la semi-synchronisation, la semi-synchronisation repose sur la réplication asynchrone. Dans ce type d'environnement, une perte de données peut se produire après un basculement. Lorsque votre base de données n'est pas configurée correctement et utilise une approche de réplication à l'ancienne, cela peut être pénible, en particulier lorsqu'il s'agit de la cohérence des données et des transactions perdues.
Une autre chose importante à noter avec la perte de données avec MHA est lorsque GTID est utilisé sans semi-synchronisation activée. MHA avec GTID ne se connectera pas via ssh au maître mais essaiera d'abord de synchroniser les journaux binaires pour la récupération de nœud avec les esclaves. Cela peut potentiellement conduire à plus de perte de données que par rapport à MHA non-GTID avec la semi-synchronisation non activée.
Corrections/Résolution
Lorsque vous effectuez un basculement automatique, créez une liste de scénarios lorsque vous vous attendez à ce que votre MHA bascule. Étant donné que MHA traite de la réplication maître-esclave, nos conseils pour éviter la perte de données sont les suivants :
- Activer la réplication semi-synchrone sans perte (existe dans la version MySQL 5.7)
- Utilisez la réplication basée sur GTID. Bien sûr, vous pouvez utiliser la réplication traditionnelle en utilisant les coordonnées x &y de binlog. Cependant, cela rend les choses plus difficiles et prend du temps lorsque vous devez localiser une entrée de journal binaire spécifique qui n'a pas été appliquée sur l'esclave. Ainsi, avec GTID dans MySQL, il est plus facile de détecter les transactions erronées.
- Pour la conformité ACID de votre réplication maître-esclave MySQL, activez ces variables spécifiques :sync_binlog =1, innodb_flush_log_at_trx_commit =1. Cela coûte cher car cela nécessite plus de puissance de traitement lorsque MySQL appelle la fonction fsync() lors de la validation, et les performances peut être lié au disque en cas de nombre élevé d'écritures. Cependant, l'utilisation de RAID avec un cache de sauvegarde sur batterie permet d'économiser vos E/S de disque. De plus, MySQL lui-même s'est amélioré avec la validation du groupe de journaux binaires, mais l'utilisation d'un cache de sauvegarde peut économiser certaines synchronisations de disque.
- Exploitez la réplication parallèle ou la réplication esclave multithread. Cela peut aider vos esclaves à devenir plus performants et éviter les retards de l'esclave par rapport au maître. Vous ne voulez pas que votre basculement automatique se produise lorsque le maître n'est pas accessible du tout via une connexion ssh ou tcp, ou s'il rencontre une panne de disque et que vos esclaves sont à la traîne. Cela pourrait entraîner une perte de données.
- Lorsque vous effectuez un basculement en ligne ou manuel, il est préférable de l'effectuer pendant les périodes creuses afin d'éviter tout incident inattendu susceptible d'entraîner une perte de données. Ou pour éviter des recherches fastidieuses dans vos journaux binaires alors qu'il y a beaucoup d'activité en cours.
MHA indique que l'APP n'est pas en cours d'exécution ou que le basculement ne fonctionne pas. Que dois-je faire ?
L'exécution de vérifications à l'aide du script intégré masterha_check_status vérifiera si le script mastreha_manager est en cours d'exécution. Sinon, vous obtiendrez une erreur comme ci-dessous :
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Cependant, il existe certains cas où vous pourriez obtenir NOT_RUNNING même lorsque masterha_manager est en cours d'exécution. Cela peut être dû au privilège de l'utilisateur ssh_user que vous avez défini, ou vous exécutez masterha_manager avec un utilisateur système différent, ou l'utilisateur ssh a rencontré une autorisation refusée.
Corrections/Résolution :
MHA utilisera le ssh_user défini dans la configuration si spécifié. Sinon, utilisera l'utilisateur système actuel que vous utilisez pour appeler les commandes MHA. Lors de l'exécution du script masterha_check_status par exemple, vous devez vous assurer que le masterha_manager s'exécute avec le même utilisateur que celui spécifié dans ssh_user dans votre fichier de configuration, ou l'utilisateur qui s'interfacera avec les autres nœuds de base de données du cluster. Vous devez vous assurer qu'il dispose de clés SSH sans mot de passe ni mot de passe afin que MHA n'ait aucun problème lors de l'établissement de la connexion aux nœuds surveillés par MHA.
Notez que vous avez besoin de ssh_user pour avoir accès aux éléments suivants :
- Peut lire les journaux binaires et de relais des nœuds MySQL que MHA surveille
- Doit avoir accès aux journaux de surveillance MHA. Consultez ces paramètres dans MHA :master_binlog_dir, manager_workdir et manager_log
- Doit avoir accès au fichier de configuration MHA. Ceci est également très important. Lors d'un basculement, une fois le basculement terminé, il essaiera de mettre à jour le fichier de configuration et de supprimer l'entrée du maître mort. Si le fichier de configuration n'autorise pas ssh_user ou l'utilisateur du système d'exploitation que vous utilisez actuellement, il ne mettra pas à jour le fichier de configuration, ce qui entraînera une escalade du problème si le sinistre se reproduit.
Retards maîtres candidats, comment forcer et éviter les échecs de basculement
En référence au wiki de MHA, par défaut, si un esclave derrière le maître plus de 100 Mo de journaux de relais (=doit appliquer plus de 100 Mo de journaux de relais), MHA ne choisit pas l'esclave comme nouveau maître car il prend trop de temps pour récupérer .
Corrections/Résolution
Dans MHA, cela peut être remplacé en définissant le paramètre check_repl_delay=0. Lors d'un basculement, MHA ignore le délai de réplication lors de la sélection d'un nouveau maître et exécute les transactions manquantes. Cette option est utile lorsque vous définissez candidate_master=1 sur un hôte spécifique et que vous souhaitez vous assurer que l'hôte peut être un nouveau maître.
Vous pouvez également intégrer pt-heartbeat pour obtenir une précision du décalage esclave (voir ce post et celui-ci). Mais cela peut également être atténué avec la réplication parallèle ou les esclaves de réplication multi-thread, présents depuis MySQL 5.6 ou, avec MariaDB 10 - prétendant avoir un coup de pouce avec une amélioration de 10 fois de la réplication parallèle et des esclaves multi-thread. Cela peut aider vos esclaves à répliquer plus rapidement.
Les mots de passe MHA sont exposés
La sécurisation ou le cryptage des mots de passe n'est pas quelque chose qui est géré par MHA. Les paramètres password ou repl_password seront exposés via le fichier de configuration. So your system administrator or security architect must evaluate the grants or privileges of this file as you don’t want to expose valuable database/SSH credentials.
Fixes/Resolution:
MHA has an optional parameter init_conf_load_script. This parameter can be used to have a custom script load your MHA config that will interface to e.g. a database, and retrieve the user/password credentials of your replication setup.
Of course, you can also limit the file attribute of the configuration and the user you are using, and limit the access to the specific Ops/DBA's/Engineers that will handle MHA.
MHA is Not My Choice, What Are the Alternatives for replication failover?
MHA is not a one-size-fits-all solution, it has its limitations and may not fit your desired setup. However, here's a list of variants that you can try.
- PRM
- Maxscale with Mariadb Monitor or MariaDB Replication Manager (MRM)
- Orchestrator
- ClusterControl
