MHA在使用过程中，遇到过哪些坑
背景介绍
上回介绍了黑枸杞少年月月如何用Python写出DB平台的过程。
这回给大家介绍一个乙方同学顺子，顺子因被外派长期驻点外地。
与家人聚少离多，这样他也有了很多的时间用来研究技术。
例如：如何优雅吃羊腿；怎么样可以让本地的同学请吃羊腿；吃羊腿的步骤；等等这次他将用自己血泪教训带我们趟过MHA的坑，且看：MHA坑知多少！
MHA 简介
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高
MHA坑知多少
2.1、 masterha_check_repl(1130,1045)
故障原因:
此账号没有权限登录到对应的机器上
处理方法:
为对应的用户授权即可
2.2、masterha_check_repl(Can't exec "mysqlbinlog")
故障原因:
从当前的环境变量中找不到 mysqlbinlog 命令
解决方法:
将 mysqlbinlog 的路径添加到 环境变量中
2.3、 masterha_check_repl(rep no exist or does not have REPLICATIONSLAVE privilege)
故障原因
缺少 REPLICATION SLAVE 权限
解决方法:
为同步账号添加 REPLICATION SLAVE 权限即可, 注意,是所有节点都添加, 保证主从切换后都可以正常使用。
2.4、event_scheduler
故障原因:
这个是由于部属的 mha 版本没有跟上 数据库的版本. 在检测长连接时, 由于系统新增加了event_scheduler 功能,且属于打开的状态,那么此用户会一直存在, mha 检测时将其列为长连接,所以出现上面错误
解决方法:
临时解决方法: 禁用 event_scheduler, set global event_scheduler = 0;
长久之计,按下面方式修改源码:
2.5、 mha 管理 vip, 节点之间的网卡名不一样，切换会失败。
解决方法:
* 改网卡名
* 改切换脚本
2.6、 mha 管理 vip, ssh 默认端口非22
切换会失败
解决方法:
* 改默认端口
* 改切换脚本
注: 在线切换 和 故障切换脚本QQ群中提供 群号：748415432
2.7、 使用 GTID 时切换的坑
gtid_mode=1; auto_position=0 模式, 配置 binlog server 选项
虽然打开了 GTID, 但同步依旧使用的是log_file + position 模式同步数据, 切换时依旧自动转成 auto_position=1 模式, 转换后很有可能出来 1236 同步错误. 下面两段代码解释了为什么会依旧使用 auto_position=1 模式 .
2.8、 gtid_mode=1; auto_position=0模式,
配置 binlog server 选项, 同时配置了 use_gtid_auto_pos=0
看似解决了上面的问题, 但引入了一个最大的问题, 不补尝原主实例的差异数据了, 这就是说, 原主库任何情况下出现异常都属于机器挂的情况‘
2.9、 gtid_mode=1; auto_position=1模式,
没有配置 binlog server 选项, 依旧补不了日志。
2.7 ~ 2.9 解决方案：
开启 gitd 后, 最好的方案就是 基于 gtid 同步, 且使用 auto_position=1, 同时配置 binlog server 选项。
2.10、如果新实例,则需要执行一个事务,才可以被识别为开启 了 GTID 模式
[server default]
# 这边是 连接 MySQL 的账号与密码， 如果端口发生改变， 也要写上相应的端口, 默认为 330
port=3306
user=rootpassword=123456# 这边是连接机器的 ssh 用户,密码使用互信方式实现
ssh_user=root# 这边复制账号
repl_user=repl
repl_password=123456
master_binlog_dir= /data/mysql/mysqldata3306/binlog
master_ip_failover_script= /etc/mha/scripts/
master_ip_failover_new
master_ip_online_change_script= /etc/mha/scripts/master_online_change_new
manager_workdir=/etc/mha/app1manager_log=/etc/mha/log/mha/manager.log
[server1]
hostname=192.168.1.20
candidate_master=1
master_binlog_dir= /data/mysql/mysqldata3306/binlog
[server2]
hostname=192.168.1.2
1candidate_master=1
master_binlog_dir= /data/mysql/mysqldata3306/binlog
[server3]
hostname=192.168.1.22
candidate_master=1
master_binlog_dir= /data/mysql/mysqldata3306/binlog
[server4]
hostname=192.168.1.23
candidate_master=1
master_binlog_dir= /data/mysql/mysqldata3306/binlog
[binlog1]
hostname=192.168.1.20
[binlog2]
hostname=192.168.1.21
[binlog3]
hostname=192.168.1.22
[binlog4]
hostname=192.168.1.23结尾
想要完美的避开上面的坑, 建议:
* 使用高版本的 MHA, 可以解决上面切换的坑.
* 如果打开了 GTID 模式,则使用 auto_position=1 同步模式,同时 MHA 的配置文件中 配置[binlog1] 选项, 地址写上原主库地址就好, 不需要真实配置一个 binlog server 服务器