mysql 第四十一篇文章~MHA一些方面的探讨一

一 简介: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的核心脚本,我是不懂的..

这是我的一点心得,有问题可以及时留言，我也是菜鸟 哈哈

mysql 第四十一篇文章~MHA一些方面的探讨一

标签：tin   arch   cond   hang   根据   观察   success   eterm   search