一 简介:MHA上线已经很久了,却没有写一篇文章,今天来说说
二 初步思路: 我今天就从日志角度的方面分析下,说说自己的思路
三 切换流程
一 拷贝binlog阶段
1 Getting Latest Slaves Phase..
The latest binary log file/position on all slaves is mysql-bin.000102:219273659(根据命令得到最新的binlog信息)
The oldest binary log file/position on all slaves is mysql-bin.000102:219273659(根据命令得到最旧的binlog信息)
注意 此处得到的binlog信息是读取所有slave(配置文件中)的 (Read_Master_Log_Pos和Master_Log_File)
2 Saving Dead Master‘s Binlog Phase (进行binlog保留与拷贝)
1 执行相关命令 save_binary_logs --command=save --start_file=mysql-bin.1 --start_pos=position --binlog_dir=/data/mysql/data/ --output_file=/var/tmp/xx.binlog --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.56
注意 1 根据阶段1得到的binlog信息进行保留，会保存在mha管理机文件夹中,命名为XX.binlog
二 新主选举阶段
1 Determining New Master Phase..(进行新主选举阶段)
1 Finding the latest slave that has all relay logs for recovering other slaves (寻找拥有最新relay log从库用作恢复其他从库)
2 Searching new master from slaves.(从这些从库里寻找新的从库作为主库)
3 Candidate masters from the configuration file(从配置文件中选择优先级配置的主,这里要注意,如果配置了优先级策略,优先级高的会成为主,有的设置是无法成为主的)
4 New master is IP(选举出新主)
四 新主恢复阶段
1 New Master Diff Log Generation Phase..(主库对比binlog与relay-log差异化日志)
2 Master Log Apply Phase..(主库应用binlog与relay-log差异化日志)
All relay logs were successfully applied(主库差异化日志应用完成)
3 Getting new master‘s binlog name and position.（得到新主的binlog信息)
4 All other slaves should start replication from here（生成其他从库CHANGE语句)
5 Executing master IP activate script（执行脚本切换,VIP进行漂移)
db_master_ip_failover --command=start --ssh_user=root --orig_master_host= --orig_master_ip= --orig_master_port= --new_master_host= --new_master_ip= --new_master_port= --new_master_user=‘‘ --new_master_password=‘‘
五 其他从库恢复阶段
1 Slaves Recovery Phase.(开启从库恢复流程)
1 Starting Parallel Slave Diff Log Generation Phase.开启并行的从库日志relay-log对比
2 Starting Parallel Slave Log Apply Phase. 开启并行的从库日志应用
注意 这里所用的工具也是 apply_diff_relay_logs，我们可以发现,这个工具在MHA进行数据差异化对比和补全方面发挥了非常重要的作用,这里的relay-log对比应该是其他所有slave的relay-log对比
2 Executed CHANGE MASTER.(从库重新CHANGE到主库)
1 All relay logs were successfully applied. (确保所有的relay-log完成,也就是前一步都应用完成)
2 Resetting slave and starting replication from the new master(reset slave和重新change)
3 start slave (开启从库应用)
六 恢复完成
七 相关脚本作用说明
1 save_binary_logs 如果master的二进制日志可以存取的话，保存复制master的二进制日志，最大程度保证数据不丢失
2 apply_diff_relay_logs 相对于最新的slave，生成差异的中继日志并将所有差异事件应用到其他所有的slave
1 For generating differential log events 对比示例
apply_diff_relay_logs --command=generate_and_send --target_version=5.1.56 --scp_user=s --scp_host=s --latest_mlf=s --target_mlf=s --target_rmlp=i --relay_log_info=s --server_id=i --diff_file_readtolatest=s --target_version=s --workdir=s --timestamp=s
2 applying relay log 应用示例
apply_diff_relay_logs --command=apply --target_version=5.1.56 --slave_user=s --slave_host=s --slave_ip=s --slave_port=i --apply_files=file1,file2.. --workdir=s --timestamp=s --slave_pass=xxx
3 purge_relay_logs删除中继日志而不阻塞sql线程,作用于从库
4 db_master_ip_failover VIP漂移(需要自己编写,网上有2种流传的成熟版本,分别为shell/perl版本)
5 masterha_secondary_check 第二检测脚本,建议添加,选定的IP为配置文件的从库即可
八 自动切换 相关切换失败的说明
1 所有的复制功能(IO/SQL)线程都运行正常
2 所有的show slave status的输出中Seconds_Behind_Master参数小于或者等于running_updates_limit秒，如果在切换过程中不指定running_updates_limit,那么默认情况下running_updates_limit为1秒
3 第二检测脚本配置的IP不正确,可能也会导致切换失败,比如切换一次后再次进行切换(本人曾遇到过)
九 些注意点
1 MHA不建议采用手动切换,无论什么情况下,我们都是采用故障切换方式
2 0.56的MHA已经可以支持GTID模式,更快捷,更安全
3 对于MHA的监控可以采用监控MHA进程即可,一旦触发切换,MHA进程就会死掉.
4 MHA manager 一旦发生切换失败,一定要观察日志,分析原因。
5 有懂perl的技术人员可以深究下mha的核心脚本,我是不懂的..
这是我的一点心得,有问题可以及时留言，我也是菜鸟 哈哈
