共计 8299 个字符，预计需要花费 21 分钟才能阅读完成。
丸趣 TV 小编给大家分享一下 MHA 调研与应用的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
MHA 调研与应用 一、问题与需求
1.1、问题汇总
1、没有工具来快速切换集群主库，如果切换主库，需要 DBA 手动修改从库指向，修改元信息等
2、需要能快速上线，不影响当前架构
3、需要全部自动化处理，方便 DBA 使用，例如检查，操作，展示等
二、MHA 介绍 2.1、什么是 MHA
MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案，它由日本 DeNA 公司 youshimaton 开发，是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。
在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
2.2、MHA 原理
phase 1: Configuration Check Phase..
mha will check the mha default file,then it can get the status of all mysql nodes and the relationship between them, who is master ,who is slave and who is dead ,who is alive.
Phase 2: Dead Master Shutdown Phase
使用 master_ip_failover_scirpt 和 shutdown script to shutdown or inactive the dead master ,（sush as IP or DNS switching，which was defined in a self-defined script in advance ,just in case of split-brain）and I tend to use python.
（执行 master_ip_failover_script –command=stopssh 使原主库 IP 失效；执行 SHUTDOWN script –command=stopssh，关闭原主库）
Phase 3: Master Recovery Phase
3.1 比较所有从库的 bin log 的 pos 点，找出 latest binlog file pos 和 oldest file pos
3.2 尝试去原主库上获取 binlog
3.3 根据 no_master、candidate_master 和各从库延迟情况，选出新主库；获取新主库的日志缺失情况
3.4 给新选出来的主库补日志，并激活新主库。（生成 change master to 语句）
Phase 4: Slaves Recovery Phase
4.1 给从库补日志：从主库上补日志，或者，从 lastest 从库上给其他从库补日志
4.2 execute change master to command in all avaiable slaves , which is generated in former steps
Phase 5: New master cleanup
清除新主库的 slave info
[info] * Phase 1: Configuration Check Phase..
[info] ** Phase 1: Configuration Check Phase completed.
[info] * Phase 2: Dead Master Shutdown Phase..
[info] * Phase 2: Dead Master Shutdown Phase completed.
[info] * Phase 3: Master Recovery Phase..
[info] * Phase 3.1: Getting Latest Slaves Phase..
[info] * Phase 3.2: Saving Dead Master s Binlog Phase..
[info] * Phase 3.3: Determining New Master Phase..
[info] * Phase 3.3: New Master Diff Log Generation Phase..
[info] * Phase 3.4: Master Log Apply Phase..
[info] * Phase 3: Master Recovery Phase completed.
[info] * Phase 4: Slaves Recovery Phase..
[info] * Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
[info] * Phase 4.2: Starting Parallel Slave Log Apply Phase..
[info] * Phase 5: New master cleanup phase..
[info] Sending mail..
2.3、MHA 优势
1、不影响服务器性能，易安装，不改变现有部署
2、故障切换（实现自动故障检测和故障转移，通常在 30 秒以内;）
3、数据一致性保证
2.4、mha 模式
按节点分为：manage/node 模式，即 MHA 管理机器与集群 node 节点
按切换分为：online/failover 模式切换，即在线切换与主库损坏切换
2.5、MHA 要求
1、最少一主一从
2、ssh 互信
3、mysql 账号
4、linux 系统
5、mysql 版本 5.0 及以后
6、mysqlbinlog 必须是 3.3 及以上版本
7、log-bin 必须在每一个可称为 master 的 mysql 服务器上设置
8、所有 mysql 服务器的复制过滤规则必须一致
9、必须在能成为 master 的服务器上设置复制账户
10、基于语句的复制时，不要使用 load datainfile 命令
11、关闭 relay_log_purge，需要脚本 / 手动定期清理（清理方式：set global relay_log_purge=1;flush logs;）
2.6、MHA 版本选择
从 MHA 的 0.56 版本开始，也支持基于 GTID 的故障切换。MHA 会自动检测 mysqld 是否在 GTID 运行，如果 GTID 开启，MHA 就实现带 GTID 的故障切换，如果没有启用，MHA 就使用基于 relay log 的故障切换。
2.7、重要参数
ignore_fail=1 忽略报错
candidate_master=1 1：优先成为 master 0：不优先
no_master=1 1：不能成为 master 0：可以成为 master
三、MHA 实现
3.1、架构图
3.2、具体实现与自动化 3.2.1、mha 操作、部署、检查等程序 –mhacluster
集成 mha 日常操作，部署，检查，修复等功能
包括：
1 添加互信关系
2 安装 MHA 软件包等
3 授权相关账户
4 检查 ssh、repl、conf 正确性等
5 自动修复问题集群
6 自动更新每个集群的 conf 文件
7 自动更新别名，方便使用
8 自动清理 relaylog
功能情况如下
3.2.2、mhacluster 功能 – 互信
中控 /MHA 管理机到所有机器互信 完成
添加集群内部互信，利用 make_ssh_authentication.sh 脚本来自动添加互信
3.2.3、mhacluster 功能 – 授权
需要 super 权限的数据库用户，来源 集群的所有实例 IP 完成
3.2.4、mhacluster 功能 –relay_log_purge 设置
默认设置为 off，利用脚本任务，定期清理
利用 MHA 自带的 purge 脚本，部署到 crontab 就可以了（安装完 node 自动会有，暂时没有使用此方式，模拟此方式进行清理）
3.2.5、mhacluster 功能 –mysqlbinlog 收集更新
因目前存在 binlog 目录不固定，暂时先利用脚本收集入库至元信息
3.3.6、mhacluster 功能 – 安装软件包
所有实例安装 2 个软件包
rpm -ivh /data/soft/perl-DBD-MySQL-4.013-3.el6.x86_64.rpm
rpm -ivh /data/soft/mha4mysql-node-0.56-0.el6.noarch.rpm
3.3.7、mhacluster 功能 – 检查 ssh/repl/conf
检查 mha 要求的 masterha_check_ssh/repl
检查 mha 配置文件与元信息是否一致
3.3.8、mhacluster 功能 – 自动修复问题集群
自动修复 ssh/repl/conf 检查问题的集群
3.3.9、mhacluster 功能 – 更新别名与 mha 配置文件
更新 mha 的常用别名
alias masterha_check_ssh.1= masterha_check_repl –conf=/data/masterha/conf/1#testdb
alias masterha_check_repl.1= masterha_check_repl –conf=/data/masterha/conf/1#testdb
注：此处的 1 为集群号
更新 mha 配置文件
根据元信息来更新 mha 的 conf 文件
3.3.9、mhacluster 功能 – 授权 mha 要求账户
自动授权 mha 要求的账号
3.4、元信息字段情况
cluster_id 集群号
cluster_name 集群名
role：Master，Slave,Backup 角色
binlog_dir binlog 地址
no_master 不能成为 master，1 不能成为 master，0 可以
candidate_master 是否优先可切为 master，1 优先，0 不优先 ,
mha_write_into_conf 是否写到配置文件，1 写入，0 不写入
3.5、MHA 配置
3.5.1、MHA 默认配置文件
[root@dbmon conf]# vi /etc/masterha_default.cnf
[server default]
manager_workdir=/data/masterha/work/
user=dba
password=
ssh_user=root
repl_user=repadm
repl_password=
ping_interval=30
shutdown_script=
master_ip_failover_script= /data/mha/master_ip_failover_script.py 注：failover 模式切换主脚本
master_ip_online_change_script= /data/mha/master_ip_online_change_script.py 注： online 模式切换主脚本
report_script= /data/mha/send_report.py 注： 发送切换后邮件主脚本
3.5.2、mha 的集群 conf 配置文件
根据元信息自动生成
[server1]
hostname=10.0.0.1
port=3306
master_binlog_dir=/data/my3306/
ignore_fail=1
no_master=1
candidate_master=0
[server2]
hostname=10.0.0.2
port=3306
master_binlog_dir=/data/my3306/
ignore_fail=1
no_master=0
candidate_master=0
3.6、切换程序 –mhaswitch
切换程序，利用 Python 封装，方便日常切换使用
支持批量切换集群
切换方式：online/dead 模式切换，即原主库存活切换，原主库故障切换
3.6.1、mhaswitch 架构
注：其他辅助脚本暂时不标注
3.6.2、mhaswitch 功能 – 展示切换信息
可以展示集群的实例信息，如下
3.6.3、mhaswitch 功能 –2 种切换方式
支持 online 模式与 failover 模式 切换（对应程序的 alive，dead）
online 模式：可选原主库是否作为新主库的从库
failover 模式：关闭原主库进行切换
3.6.4、mhaswitch 辅助脚本 –master_ip_failover_script.py 功能
1 当传入命令为 stopssh 或 stop，即关闭原主库
2 等 2 秒检查原主库是否关闭，没有关闭会 print old master still run,please check , 程序退出
3 当传入命令为 start 时，开始进行元数据的修改
4 修改域名 -IP 的对应关系
5 设置新主库 read_only=off，同时修改配置文件
6 修改原主库 read_only=on，同时修改配置文件
3.6.5、 mhaswitch 辅助脚本 –master_ip_online_change_script.py 功能
1 当传入命令为 stopssh 或 stop，即设置原主库为 read_only
2 检查原主库是否为 read_only，如果没有 read_only 会 print not read_only,please check , 程序退出
3 当传入命令为 start 时，开始进行元数据的修改
4 修改域名 -IP 的对应关系
5 设置新主库 read_only=off，同时修改配置文件
6 修改原主库 read_only=on，同时修改配置文件
3.6.6、mhaswitch 辅助脚本 –send_report.py 功能
1 发送 failover 模式切换的日志，切换结果
2 发送 MHA 配置文件地址
3 老主库 IP，端口
4 新主库 IP，端口
5 库名，服务名
6 检查切换后的集群状态（表格形式）：
集群号，IP，角色，是否可以连接，slave sql 线程，slave io 线程，slave 所指主库 host 检查，slave 所指主库端口检查，slave 延迟，连接数，/data 空间情况，只读情况，时间
3.6.7、mhaswitch 辅助脚本 –online_switch_send_report.py 功能
1 发送在线切换的日志，切换结果
2 发送 MHA 配置文件地址
3 老主库 IP，端口
4 新主库 IP，端口
5 库名，服务名
6 检查切换后的集群状态（表格形式）：
集群号，IP，角色，是否可以连接，slave sql 线程，slave io 线程，slave 所指主库 host 检查，slave 所指主库端口检查，slave 延迟，连接数，/data 空间情况，只读情况，时间
3.6.8、mhaswitch 辅助脚本 –change_domain_ip.sh 功能
1 更改域名 -IP 的对应关系脚本
3.7、开始切换
3.7.1、mhaswitch 使用说明
mhaswitch
请输入要切换的集群号:78 注：切换的集群号
### 请输入集群 [78] 主库的状态【alive/dead】:alive 注：选择切换方式
1 alive，不关闭原主库
2 dead，关闭原主库
将利用 MHA 的 online 模式切换，主库不会关闭，且 老主库 是否作为 新集群 的 从库 呢？【yes/no】, 默认 no:yes 注：选择 alive 后：需要选择 原主库 是否 作为新主库的从库，yes 是，no 不做（即设置 read_only 后不关闭）
### 是否进行切换【yes/no】, 默认 no:yes 注：是否确认开始切换，yes 确认即开始切换，no 退出
3.7.2、切换后检查
1 查看 mhaswitch 输出
2 查看邮件
3 查看实例状态报表
4 查看新主库访问等
5 检查数据一致性等
3.8、切换举例
此处只举例一个 online 模式的切换，failover 模式类似
3.8.1、切换前集群拓扑
3.8.2、mhaswitch 切换
3.8.3、切换后
拓扑情况
邮件情况
输入用时： 10 秒 左右
切换用时： 3- 5 秒左右
检查、更新及邮件用时： 5 秒
总计：18-20 秒左右，实际影响业务写时间为 3 - 5 秒左右
四、监控
4.1、MHA 日常检查监控
检查 ssh、repl、conf 正确性，检查程序为 mhacluster，结果入库并利用 django 前端展示
命令为：
python mhacluster.py –options=check_all_mha_ssh_repl_conf
前端报表为：
且支持自动修复，即根据报错情况进行修复，命令如下：
python mhacluster.py –options=auto_repair_all_mha_fail
4.2、relaylog_purge 监控
清理过期 relay_log，并检查程序运行状态及清理后状态，入库并前端展示，命令如下
python mhacluster.py –options=purge_relaylog_all
前端：
4.3、实例状态检查
检查实例运行状态，包括 readonly，从库 IO,SQL 线程，从库所指主库 IP,port 是否正确，主从延迟，连接数，空间情况等，来方便查看集群切换后的状态，可快速定位问题
python mysql_check.py –options=check_all
前端报表如下：
五、常见切换报错及处理
5.1、切换常见情况
1 没有切换，元信息等都没有更改
2 切换了，部分从库实例切换失败
5.2、MHA 的 masterha_check_ssh/repl 检查失败，无法切换
情况：没有切换，元信息没有修改
原因：
masterha_check_repl 检查失败的原因有多种：
1 无信任关系
2 账户权限问题
3 无可切为主库设置问题等
解决：
1,2 问题可以通过初始化 mha 环境来解决
python mhacluster.py –options=add_mha_single_cluster –cluster_ids=1,2,3
3 问题：数据库不可切，优先切，是否写入配置文件 配置错误问题，改正确即可
5.3、MHA 切换，部分从库切换失败
情况：已经切换了，部分从库有问题
原因：原因比较复杂，例如网络，本身 change 命令无法执行（例如 5.7 的某些配置导致）等
处理：
1 检查实例状态，确认哪些实例有问题
查看报表：实例状态即可确认，例如：
2 修复切换失败的从库
根据日志等情况进行修复或者重做。
六、线上表现及优点
6.1、线上切换
目前已经成功在线上运行 4 个月以上，已经切换线上集群 6 个以上（线上测试环境切换 30+），暂时没有发现问题
真正切换耗时大约在秒级（多数在 3 -5s 之间）
6.2、使用 MHA 环境 之前的情况
1、没有方便的工具来快速切换集群主库，发生主库故障时：
需要 DBA 花费 5 分钟手动修改从库指向，2- 3 分钟检查集群状态，3- 5 分钟修改元信息，
实际停机操作时间 3 - 5 分钟；等共需要 10-20 分钟
（仅 DBA 操作）
2、没有工具快速显示某集群拓扑情况
3、没有工具快速检查实例运行情况
6.3、使用 MHA 环境 后情况
1、利用 mhaswitch 工具来快速切换主库
1 可以降低丢失数据的风险
2 影响写入时间少，秒级
切换前后共需要 5 分钟左右（仅 DBA 操作），实际停机操作：3-30s 左右（如果在线切换大致在 3 -5s，如果是停原主库切换，则大于 10s）
DBA 效率提升 50%-75% 左右，快的话总时间可控制在 1 分钟内
线上实际操做：输入信息 10s 左右，切换影响写入 3-5s 左右，更新与检查等 9s 左右，共计 22-24s 左右
3 mhacluster 集成部署，几个小时即可自动部署全部 mysql 实例（目前近 700 个实例，近 500 台机器，实际部署与检查大约 4 - 6 个小时）
4 无需 DBA 手动修改主从，节约手动操作时间约 10-20 分钟
5 无需 DBA 手动修改元信息, 节约修改元信息时间 3 - 5 分钟左右
无需 DBA 手动调整域名 IP 关系，节约调整域名 IP 时间 1 - 3 分钟左右
6 封装 MHA，方便 DBA 使用，无需繁琐命令
7 邮件程序，发送信息全，可快速查看切换结果与日志等
2、查询集群拓扑工具 qmysql，1 秒内查看集群拓扑
3、检查集群状态工具 mysql_check，查询近 700 个实例，近 500 台机器 仅需 30s 左右
4、django 前端展示，MHA 监控，报表，方便监控 MHA 情况与排错等
以上是“MHA 调研与应用的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
