MHA通过监控日志分析原理（附中文解释）

最新推荐文章于 2023-09-05 11:24:12 发布
最新推荐文章于 2023-09-05 11:24:12 发布
阅读量1.2k 收藏 3
点赞数 1
CC 4.0 BY-SA版权
分类专栏： MySQL 文章标签： MHA 主从在线切换 主从故障切换
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_44714603/article/details/93528839

MHA是一款用来进行主从故障在线切换的工具，为了最大程度的保持数据的一致性，对于其切换的原理分析就尤为重要。 所以下面我们就直观的从MHA的切换日志这个角度来进行具体的原理分析

文章目录

MHA工作原理总结

  • 从宕机崩溃的master保存二进制日志文件（binlog events）

  • 识别有最新更新的slave

  • 应用差异的中继日志（relaylog）到其他slave

  • 应用从master保存的二进制日志事件（binlog events）

  • 提升一个slave为新的master

  • 使用其他的slave连接新的master进行复制

SSH互信登录配置

英文日志

[root@Rslavemha3 ~]# masterha_check_ssh --conf=/etc/masterha/app1/app1.cnf
Tue Apr 23 08:29:25 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 23 08:29:25 2019 - [info] Reading application default configurations from /etc/masterha/app1/app1.cnf..
Tue Apr 23 08:29:25 2019 - [info] Reading server configurations from /etc/masterha/app1/app1.cnf..
Tue Apr 23 08:29:25 2019 - [info] Starting SSH connection tests..
Tue Apr 23 08:29:26 2019 - [debug] 
Tue Apr 23 08:29:25 2019 - [debug]  Connecting via SSH from root@172.16.12.1(172.16.12.1:22) to root@172.16.12.2(172.16.12.2:22)..
Tue Apr 23 08:29:26 2019 - [debug]   ok.
Tue Apr 23 08:29:26 2019 - [debug]  Connecting via SSH from root@172.16.12.1(172.16.12.1:22) to root@172.16.12.3(172.16.12.3:22)..
Tue Apr 23 08:29:26 2019 - [debug]   ok.
Tue Apr 23 08:29:27 2019 - [debug] 
Tue Apr 23 08:29:26 2019 - [debug]  Connecting via SSH from root@172.16.12.2(172.16.12.2:22) to root@172.16.12.1(172.16.12.1:22)..
Tue Apr 23 08:29:26 2019 - [debug]   ok.
Tue Apr 23 08:29:26 2019 - [debug]  Connecting via SSH from root@172.16.12.2(172.16.12.2:22) to root@172.16.12.3(172.16.12.3:22)..
Tue Apr 23 08:29:26 2019 - [debug]   ok.
Tue Apr 23 08:29:27 2019 - [debug] 
Tue Apr 23 08:29:27 2019 - [debug]  Connecting via SSH from root@172.16.12.3(172.16.12.3:22) to root@172.16.12.1(172.16.12.1:22)..
Tue Apr 23 08:29:27 2019 - [debug]   ok.
Tue Apr 23 08:29:27 2019 - [debug]  Connecting via SSH from root@172.16.12.3(172.16.12.3:22) to root@172.16.12.2(172.16.12.2:22)..
Tue Apr 23 08:29:27 2019 - [debug]   ok.
Tue Apr 23 08:29:27 2019 - [info] All SSH connection tests passed successfully.
[root@Rslavemha3 ~]#

中文解释

[root@Rslavemha3 ~]# masterha_check_ssh——conf=/etc/masterha/app1/app1.cnf
2019年4月23日星期二08:29 -[警告]未找到全局配置文件/etc/masterha_default.cnf。跳过。
2019年4月23日星期二08:29 -[信息]从/etc/masterha/app1/app1.cnf.读取应用程序默认配置。
2019年4月23日星期二08:29 -[信息]从/etc/masterha/app1/app1.cnf.读取服务器配置。
2019年4月23日星期二08:29:25 -[信息]开始SSH连接测试。
2019年4月23日星期二8:29:26 -[调试]
2019年4月23日星期二8:29 -[调试]通过SSH从root@172.16.12.1(172.16.12.1:22)连接到root@172.16.12.2(172.16.12.2:22)。
2019年4月23日星期二8:29:26 -[调试]ok。
2019年4月23日星期二8:29 -[调试]通过SSH从root@172.16.12.1(172.16.12.1:22)连接到root@172.16.12.3(172.16.12.3:22)。
2019年4月23日星期二8:29:26 -[调试]ok。
2019年4月23日星期二8:29:27 -[调试]
2019年4月23日星期二8:29 -[调试]通过SSH从root@172.16.12.2(172.16.12.2:22)连接到root@172.16.12.1(172.16.12.1:22)。
2019年4月23日星期二8:29:26 -[调试]ok。
2019年4月23日星期二8:29 -[调试]通过SSH从root@172.16.12.2(172.16.12.2:22)连接到root@172.16.12.3(172.16.12.3:22)。
2019年4月23日星期二8:29:26 -[调试]ok。
2019年4月23日星期二8:29:27 -[调试]
2019年4月23日星期二8:29 -[调试]通过SSH从root@172.16.12.3(172.16.12.3:22)连接到root@172.16.12.1(172.16.12.1:22)。
2019年4月23日星期二8:29 - 27 -[调试]ok。
2019年4月23日星期二8:29 -[调试]通过SSH从root@172.16.12.3(172.16.12.3:22)连接到root@172.16.12.2(172.16.12.2:22)。
2019年4月23日星期二8:29 - 27 -[调试]ok。
2019年4月23日星期二08:29 -[信息]所有SSH连接测试都成功通过。
root@Rslavemha3 ~ #

健康检查日志

英文日志

[root@Rslavemha3 ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf 
Tue Apr 23 09:07:03 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 23 09:07:03 2019 - [info] Reading application default configurations from /etc/masterha/app1.cnf..
Tue Apr 23 09:07:03 2019 - [info] Reading server configurations from /etc/masterha/app1.cnf..
Tue Apr 23 09:07:03 2019 - [info] MHA::MasterMonitor version 0.55.
Tue Apr 23 09:07:03 2019 - [info] Dead Servers:
Tue Apr 23 09:07:03 2019 - [info] Alive Servers:
Tue Apr 23 09:07:03 2019 - [info]   172.16.12.1(172.16.12.1:3306)
Tue Apr 23 09:07:03 2019 - [info]   172.16.12.2(172.16.12.2:3306)
Tue Apr 23 09:07:03 2019 - [info]   172.16.12.3(172.16.12.3:3306)
Tue Apr 23 09:07:03 2019 - [info] Alive Slaves:
Tue Apr 23 09:07:03 2019 - [info]   172.16.12.2(172.16.12.2:3306)  Version=5.7.15-log (oldest major version between slaves) log-bin:enabled
Tue Apr 23 09:07:03 2019 - [info]     Replicating from 172.16.12.1(172.16.12.1:3306)
Tue Apr 23 09:07:03 2019 - [info]   172.16.12.3(172.16.12.3:3306)  Version=5.7.15-log (oldest major version between slaves) log-bin:enabled
Tue Apr 23 09:07:03 2019 - [info]     Replicating from 172.16.12.1(172.16.12.1:3306)
Tue Apr 23 09:07:03 2019 - [info] Current Alive Master: 172.16.12.1(172.16.12.1:3306)
Tue Apr 23 09:07:03 2019 - [info] Checking slave configurations..
Tue Apr 23 09:07:03 2019 - [info] Checking replication filtering settings..
Tue Apr 23 09:07:03 2019 - [info]  binlog_do_db= , binlog_ignore_db= 
Tue Apr 23 09:07:03 2019 - [info]  Replication filtering check ok.
Tue Apr 23 09:07:03 2019 - [info] Starting SSH connection tests..
Tue Apr 23 09:07:05 2019 - [info] All SSH connection tests passed successfully.
Tue Apr 23 09:07:05 2019 - [info] Checking MHA Node version..
Tue Apr 23 09:07:05 2019 - [info]  Version check ok.
Tue Apr 23 09:07:05 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 23 09:07:05 2019 - [info] HealthCheck: SSH to 172.16.12.1 is reachable.
Tue Apr 23 09:07:05 2019 - [info] Master MHA Node version is 0.54.
Tue Apr 23 09:07:05 2019 - [info] Checking recovery script configurations on the current master..
Tue Apr 23 09:07:05 2019 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data --output_file=/tmp/save_binary_logs_test --manager_version=0.55 --start_file=server.000001 
Tue Apr 23 09:07:05 2019 - [info]   Connecting to root@172.16.12.1(172.16.12.1).. 
  Creating /tmp if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /data, up to server.000001
Tue Apr 23 09:07:05 2019 - [info] Master setting check done.
Tue Apr 23 09:07:05 2019 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Tue Apr 23 09:07:05 2019 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mha_monitor' --slave_host=172.16.12.2 --slave_ip=172.16.12.2 --slave_port=3306 --workdir=/tmp --target_version=5.7.15-log --manager_version=0.55 --relay_log_info=/data/relay-log.info  --relay_dir=/data/  --slave_pass=xxx    //这一步就是应用差异中继日志
Tue Apr 23 09:07:05 2019 - [info]   Connecting to root@172.16.12.2(172.16.12.2:22).. 
  Checking slave recovery environment settings..
    Opening /data/relay-log.info ... ok.
    Relay log found at /data, up to Rslavemha3-relay-bin.000003
    Temporary relay log file is /data/Rslavemha3-relay-bin.000003
    Testing mysql connection and privileges..mysql: [Warning] Using a password on the command line interface can be insecure.
 done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Tue Apr 23 09:07:05 2019 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mha_monitor' --slave_host=172.16.12.3 --slave_ip=172.16.12.3 --slave_port=3306 --workdir=/tmp --target_version=5.7.15-log --manager_version=0.55 --relay_log_info=/data/relay-log.info  --relay_dir=/data/  --slave_pass=xxx
Tue Apr 23 09:07:05 2019 - [info]   Connecting to root@172.16.12.3(172.16.12.3:22).. 
  Checking slave recovery environment settings..
    Opening /data/relay-log.info ... ok.
    Relay log found at /data, up to Rslavemha1-relay-bin.000004
    Temporary relay log file is /data/Rslavemha1-relay-bin.000004
    Testing mysql connection and privileges..mysql: [Warning] Using a password on the command line interface can be insecure.
 done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Tue Apr 23 09:07:06 2019 - [info] Slaves settings check done.
Tue Apr 23 09:07:06 2019 - [info] 
172.16.12.1 (current master)
 +--172.16.12.2
 +--172.16.12.3

Tue Apr 23 09:07:06 2019 - [info] Checking replication health on 172.16.12.2..
Tue Apr 23 09:07:06 2019 - [info]  ok.
Tue Apr 23 09:07:06 2019 - [info] Checking replication health on 172.16.12.3..
Tue Apr 23 09:07:06 2019 - [info]  ok.
Tue Apr 23 09:07:06 2019 - [info] Checking master_ip_failover_script status:
Tue Apr 23 09:07:06 2019 - [info]   /usr/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=172.16.12.1 --orig_master_ip=172.16.12.1 --orig_master_port=3306 
Checking the Status of the script.. OK 
Tue Apr 23 09:07:06 2019 - [info]  OK.
Tue Apr 23 09:07:06 2019 - [warning] shutdown_script is not defined.
Tue Apr 23 09:07:06 2019 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.
[root@Rslavemha3 ~]#

中文解释

[root@Rslavemha3 ~]# masterha_check_repl——conf=/etc/masterha/app1.cnf
2019年4月23日星期二09:07:03 -[警告]未找到全局配置文件/etc/masterha_default.cnf。跳过。
2019年4月23日星期二09:07:03 -[信息]从/etc/masterha/app1.cnf.读取应用程序默认配置。
2019年4月23日星期二09:07:03 -[信息]从/etc/masterha/app1.cnf.读取服务器配置。
2019年4月23日星期二09:07:03 -[信息]MHA::MasterMonitor版本0.55。
2019年4月23日星期二09:07:03 -[信息]死机服务器:
2019年4月23日星期二09:07:03 -[信息]活服务器:
4月23日星期二09:07:03 2019 -[信息]172.16.12.1(172.16.12.1:3306)
4月23日星期二09:07:03 2019 -[信息]172.16.12.2(172.16.12.2:3306)
4月23日星期二09:07:03 2019 -[信息]172.16.12.3(172.16.12.3:3306)
2019年4月23日星期二09:07:03 -[信息]活着的奴隶:
4月23日星期二09:07:03 2019 -[信息]172.16.12.2(172.16.12.2:3306)版本=5.7.15 log(奴隶之间最古老的主版本)日志箱:启用
2019年4月23日星期二09:07:03 -[信息]复制自172.16.12.1(172.16.12.1:3306)
4月23日星期二09:07:03 2019 -[信息]172.16.12.3(172.16.12.3:3306)版本=5.7.15-log(奴隶之间最古老的主版本)日志箱:启用
2019年4月23日星期二09:07:03 -[信息]复制自172.16.12.1(172.16.12.1:3306)
2019年4月23日星期二09:07:03 -[信息]目前在世大师:172.16.12.1(172.16.12.1:3306)
2019年4月23日星期二09:07:03 -[信息]检查从属配置。
4月23日星期二09:07:03 2019 -[信息]检查复制过滤设置。
2019年4月23日星期二09:07:03 -[信息]binlog_do_db=， binlog_ignore_db=
2019年4月23日星期二09:07:03 -[信息]复制过滤检查ok。
4月23日星期二09:07:03 2019 -[信息]开始SSH连接测试。
2019年4月23日星期二09:07:05 -[信息]所有SSH连接测试都成功通过。
2019年4月23日星期二09:07:05 -[信息]检查MHA节点版本。
2019年4月23日星期二09:07:05 -[信息]版本检查ok。
2019年4月23日星期二09:07:05 -[信息]检查当前主机上的SSH公钥身份验证设置。
2019年4月23日星期二09:07:05 -[信息]健康检查:SSH到172.16.12.1是可访问的。
2019年4月23日星期二09:07:05 -[信息]主MHA节点版本为0.54。
2019年4月23日星期二09:07:05 -[信息]检查当前主服务器上的恢复脚本配置。
执行命令:save_binary_logs—命令=test—start_pos=4—binlog_dir=
最低0.47元/天 解锁文章

200万优质内容无限畅学
MySQL高可用必杀技：MHA架构从原理到实战，让你的数据库永不宕机！
专注于编程、AI、人工智能等多个领域内容研究和分析
05-21 257
MySQL高可用性解决方案MHA（Master High Availability）在电商平台等关键业务场景中发挥着重要作用，能够在主库故障时快速完成自动故障转移，减少数据库不可用时间。MHA由MHA Manager、MHA Node、MySQL主库和从库组成，通过定期健康检查、数据一致性验证和差异binlog应用等机制，确保故障转移的快速性和数据一致性。MHA的优势包括快速故障转移（通常10-30秒）、数据一致性保障、无需共享存储、兼容性强等。部署MHA需要准备环境、安装MySQL并配置主从复制....
MHA的配置及错误模拟与恢复
sjc090132的博客
09-27 1194
MHA的配置及模拟故障修复
mysql切换新的日志_MySQL--19 MHA切换日志分析
weixin_29802461的博客
01-27 412
MHA切换检测日志分析GTID模式[root@db03 ~]# tail -f /etc/mha/manager.log#在MySQL select ping:2006上出错(MySQL服务器已消失)Tue Nov 19 17:52:00 2019 - [warning] Got error on MySQL select ping: 2006 (MySQL server has gone awa...
MHA 日常管理
乐沙弥的世界
06-05 4945
MHA是众多使用MySQL数据库企业高可用的不二选择，它简单易用，功能强大，实现了基于MySQL replication架构的自动主从故障转移。本文主要描述MHA的日常相关操作，同时给出了关于MHA的相关连接，供大家参考。一、MHA的主要脚本(perl)1.manager端masterha_check_ssh              检查MHA的SSH配置状况masterha_che
MHA原理分析
weixin_30363509的博客
06-06 168
mysql复制是个异步过程，当主库上的日志还没来及传到从库上时主库发生crash容易导致主从数据不一致，例如mysql crash,os crash,掉电等，这时便引出了MHA技术。 安装基本环境介绍：一主一从 Mha manager & slave test2 192.168.1.115 Master test1 192.168.1.114 ...
MHA切换日志
DBA之路的博客
06-24 264
测试 一主两从 mysql5.7 GTID 1 启动MHA进程 sh start.sh op-yanhaihang-mha-mysql 2 制造流量 mysqlslap -udbadmin_01 -p*** -hdx-op-yanhaihang-mha-mysql1-online -P 3306 --auto-generate-sql --auto-generate-sql-load-type=write --auto-generate-sql-add-autoincrement --...
用MHA实现mysql自动故障转移(配置vip模式，非keepalive）
雅冰石的专栏
08-07 5361
一：MHA介绍 什么是mha，有什么特性 1.主服务器的自动监控和故障转移 MHA监控复制架构的主服务器，一旦检测到主服务器故障，就会自动进行故障转移。即使有些从服务器没有收到最新的relaylog，MHA自动从最新的从服务器上识别差异的relaylog并把这些日志应用到其他从服务器上，因此所有的从服务器保持一致性了。MHA通常在几秒内完成故障转移，9-12秒可以检测出主服
MHA Node 节点监控与故障切换原理
通过监控数据库主从同步状态，实现故障切换，从而保证数据库的高可用性。 ## 1.2 MHA的作用和优势 MHA的主要作用是在数据库Master节点故障时，自动切换到备用节点，保证数据库服务的持续可用。其优势包括： - ...
MHA Monitor 监控系统搭建与优化
MHA Monitor监控系统是一款用于监控数据库集群健康状况的工具，基于MHA（Mysql Master High Availability）架构原理，能够对数据库集群的主从切换、故障自动转移等过程进行监控和管理。 ## 1.2 监控系统的作用和...
mha4mysql-manager-0.58.tar和 mha4mysql-node-0.58.tar 的源码和rpm包
08-29
在日常运维中，还需要定期检查MHA的日志，分析系统状态，以及对MySQL主从复制的性能进行监控。此外，理解并熟练掌握MHA的工作原理和配置选项，有助于我们更好地应对各种复杂的数据库高可用场景。 总结来说，MHA作为...
MHA官方文档翻译
cug_jiang126com的专栏
12-22 4811
翻译by 胡儿胡儿 文中翻译有一些不足之处和略过没做翻译的部分，详细请参考英文官方文档 http://code.google.com/p/mysql-master-ha/wiki/TableOfContents?tm=6 转载请注明出处   Overview MHA能够在较短的时间内实现自动故障检测和故障转移，通常在10-30秒以内;在复制框架中，MHA能够很好地解决复制过程中的数据一
MHA自动Failover过程解析(updated) ------好东西 分享一下
wulantian的专栏
10-28 5648
允许转载, 转载时请以超链接形式标明文章原始出处和网站信息 http://www.mysqlsystems.com/2012/03/figure-out-process-of-autofailover-on-mha.html MHA自动Failover过程解析(updated) By zhang, on March 31st, 2012 MHA是一位日本MySQL大牛用P
MHA高可用配置及故障切换
最新发布
m0_56509725的博客
09-05 254
当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 mas然后将所有其他的 slave 重新指向新的 master。●使用半同步复制，可以大大降低数据丢失的风险，如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。5.mha最后再选择完成新的master之后，会再其余的slave之上执行change master操作，指向新的master，来保障mysql集群的健康性。
mysql-MHA切换或检查复制时报1142问题定位和解决
05-24 344
====模拟当前slaves之间relay log存在差异，当前master mysql服务关闭后的mha自动切换====1、在没有设置master_ip_failover_script的情况下的切换测试：测试预想结果：自动切换...
mha切换日志
weixin_33762130的博客
03-25 663
初始检测 判断主库是否已宕 一共判断了3次，均判断master mysqld不可用，但是master主机通过ssh还是能登录上去。ssh用于传输日志 通过上面的输出才知道是通过save_binary_logs脚本来判断ssh可用性的。(数据库宕) 如果这里显示的是SSH is NOT reachable，则代表master主机也已经宕机了（操作系统宕） Sat Jun 16 15:10:5...
MHA故障转移日志
Gmoon23的博客
07-27 1097
该日志在MHA管理主机中，配置文件中你所定义的日志文件中。在认定master主库宕机之后：故障转移步骤Thu Jul 27 19:19:56 2017 - [info] * Phase 1: Configuration Check Phase.. Thu Jul 27 19:19:56 2017 - [info] Thu Jul 27 19:19:56 2017 - [info] GTID fai
生产环境的常用的MHA,解决读写分离主服务器的单点故障
weixin_48191039的博客
10-21 4469
1.传统的MySQL主从架构存在的问题 只有一台主服务器负责写入 存在单点故障点 2.MHA概述 MHA (MasterHigh Availability）E前在MySQL高可用方面是一个相对成熟的解决方案，它由日本 DeNA公youshimaton（现就职于Facebook公司）开发的 —套优秀的MySQL高可用环境下故障切换和主从复制的软件 MySQL故障过程中，MHA能做到O-30秒内自动完成故障切换 并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
mysql自愈_mysql搭建MHA高可用解析
weixin_39955421的博客
01-21 360
1. MHA能做什么?主库宕机处理过程1. 监控节点 (通过配置文件获取所有节点信息)系统,网络,SSH连接性主从状态,重点是主库2. 选主(1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主(2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.(3) 如果设定有权重(candidate_master=1)...
我配置的Mha检查时出现的情况分析及解决如下
火麒马
06-13 5456
​
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值