小编给大家分享一下MHA调研与应用的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
成都网站建设哪家好，找创新互联公司！专注于网页设计、网站建设、微信开发、微信小程序、集团企业网站制作等服务项目。核心团队均拥有互联网行业多年经验，服务众多知名企业客户；涵盖的客户类型包括：成都活动板房等众多领域，积累了大量丰富的经验，同时也获得了客户的一致称扬！
1、没有工具来快速切换集群主库，如果切换主库，需要DBA手动修改从库指向，修改元信息等
2、需要能快速上线，不影响当前架构
3、需要全部自动化处理，方便DBA使用，例如检查，操作，展示等
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。
在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，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..
1、不影响服务器性能，易安装，不改变现有部署
2、故障切换（实现自动故障检测和故障转移，通常在30秒以内;）
3、数据一致性保证
按节点分为：manage/node模式，即MHA管理机器与集群node节点
按切换分为：online/failover模式切换，即在线切换与主库损坏切换
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日常操作，部署，检查，修复等功能
包括：
<1>添加互信关系
<2>安装MHA软件包等
<3>授权相关账户
<4>检查ssh、repl、conf正确性等
<5>自动修复问题集群
<6>自动更新每个集群的conf文件
<7>自动更新别名，方便使用
<8>自动清理relaylog
功能情况如下
中控/MHA管理机到所有机器互信 完成
添加集群内部互信，利用make_ssh_authentication.sh脚本来自动添加互信
需要super 权限的数据库用户，来源 集群的所有实例IP 完成
默认设置为off，利用脚本任务，定期清理
利用MHA自带的purge脚本，部署到crontab就可以了（安装完node自动会有，暂时没有使用此方式，模拟此方式进行清理）
因目前存在binlog目录不固定，暂时先利用脚本收集入库至元信息
所有实例安装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
检查mha要求的masterha_check_ssh/repl
检查mha配置文件与元信息是否一致
自动修复ssh/repl/conf 检查问题的集群
更新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文件
自动授权mha要求的账号
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不写入
[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" 注： 发送切换后邮件主脚本
根据元信息自动生成
[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
切换程序，利用Python封装，方便日常切换使用
支持批量切换集群
切换方式：online/dead 模式切换，即原主库存活切换，原主库故障切换
注：其他辅助脚本暂时不标注
可以展示集群的实例信息，如下
支持online模式与failover模式 切换（对应程序的alive，dead）
online模式：可选原主库是否作为新主库的从库
failover模式：关闭原主库进行切换
<1>当传入命令为stopssh 或 stop，即关闭原主库
<2>等2秒检查原主库是否关闭，没有关闭会print "old master still run,please check",程序退出
<3>当传入命令为start 时，开始进行元数据的修改
<4>修改域名-IP的对应关系
<5>设置新主库read_only=off，同时修改配置文件
<6>修改原主库read_only=on，同时修改配置文件
<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，同时修改配置文件
<1>发送failover模式切换的日志，切换结果
<2>发送MHA配置文件地址
<3>老主库IP，端口
<4>新主库IP，端口
<5>库名，服务名
<6>检查切换后的集群状态（表格形式）：
集群号，IP，角色，是否可以连接，slave sql线程，slave io线程，slave所指主库host检查，slave所指主库端口检查，slave延迟，连接数，/data空间情况，只读情况，时间
<1>发送在线切换的日志，切换结果
<2>发送MHA配置文件地址
<3>老主库IP，端口
<4>新主库IP，端口
<5>库名，服务名
<6>检查切换后的集群状态（表格形式）：
集群号，IP，角色，是否可以连接，slave sql线程，slave io线程，slave所指主库host检查，slave所指主库端口检查，slave延迟，连接数，/data空间情况，只读情况，时间
<1>更改域名-IP的对应关系脚本
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退出
<1>查看mhaswitch输出
<2>查看邮件
<3>查看实例状态报表
<4>查看新主库访问等
<5>检查数据一致性等
此处只举例一个online模式的切换，failover模式类似
拓扑情况
邮件情况
输入用时： 10秒 左右
切换用时： 3-5秒左右
检查、更新及邮件用时： 5秒
总计：18-20秒左右，实际影响业务写时间为3-5秒左右
检查ssh、repl、conf正确性，检查程序为mhacluster，结果入库并利用django前端展示
命令为：
python mhacluster.py --options=check_all_mha_ssh_repl_conf
前端报表为：
且支持自动修复，即根据报错情况进行修复，命令如下：
python mhacluster.py --options=auto_repair_all_mha_fail
清理过期relay_log，并检查程序运行状态及清理后状态，入库并前端展示，命令如下
python mhacluster.py --options=purge_relaylog_all
前端：
检查实例运行状态，包括readonly，从库IO,SQL线程，从库所指主库IP,port是否正确，主从延迟，连接数，空间情况等，来方便查看集群切换后的状态，可快速定位问题
python mysql_check.py --options=check_all
前端报表如下：
<1>没有切换，元信息等都没有更改
<2>切换了，部分从库实例切换失败
情况：没有切换，元信息没有修改
原因：
masterha_check_repl 检查失败的原因有多种：
<1>无信任关系
<2>账户权限问题
<3>无可切为主库设置问题等
解决：
1,2问题可以通过初始化mha环境来解决
python mhacluster.py --options=add_mha_single_cluster --cluster_ids=1,2,3
3问题：数据库不可切，优先切，是否写入配置文件 配置错误问题，改正确即可
情况：已经切换了，部分从库有问题
原因：原因比较复杂，例如网络，本身change命令无法执行（例如5.7的某些配置导致）等
处理：
<1>检查实例状态，确认哪些实例有问题
查看报表：实例状态即可确认，例如：
<2>修复切换失败的从库
根据日志等情况进行修复或者重做。
目前已经成功在线上运行4个月以上，已经切换线上集群6个以上（线上测试环境切换30+），暂时没有发现问题
真正切换耗时大约在秒级（多数在3-5s之间）
1、没有方便的工具来快速切换集群主库，发生主库故障时：
需要DBA花费5分钟手动修改从库指向，2-3分钟检查集群状态，3-5分钟修改元信息，
实际停机操作时间3-5分钟；等共需要10-20分钟
（仅DBA操作）
2、没有工具快速显示某集群拓扑情况
3、没有工具快速检查实例运行情况
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调研与应用的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！