MHA工作原理

目录

个人原创总结之 MHA工作原理

简介

MHA是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件，使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

主要流程

1）先保存mastet的binlog日志
2）对比slave01和slave02的relay-log中继日志，找到最新的slave
3）将slave01上的 relay-log差量补全到slave02上面
4）将slave01提升为新的master，然后其他从节点指向它
5）利用保存下来的所有binlog日志，恢复到slave01
6）然后其他从苦开始主从复制

MHA架构分析（由两种角色组成）

MHA Manager: 常单独部署在一台独立的机器上或者直接部署在其中一台slave上（不建议后者），可以管理多个master/slave集群，每个master/slave集群称作一个application；其作用有二：
（1）master自动切换及故障转移命令运行
（2）其他的帮助脚本运行：手动切换master；master/slave状态检测

MHA node: 运行在每台MySQL服务器上（master/slave/manager），它通过监控具备解析和清理logs功能的脚本来加快故障转移。其作用有：
（1）复制主节点的binlog数据
（2）对比从节点的中继日志文件
（3）无需停止从节点的SQL线程，定时删除中继日志

MHA优点

1）自动故障赚一块
2）主库崩溃不存在数据库一致性问题
3）不需要对当前mysql环境做重大修改
4）不需要添加额外对服务器（仅一台mangager就ok）
5）性能高，当监控mysql状态时，仅需要每秒向master发送ping信号（这里的select ping和平时我们看到的ping ：www.baidu.com不一样，前者连接被重复使用，select检查能快速返回结果；后者是基于icmp协议的，效率低一点）

MHA组件

1)、 Manager工具:
– masterha_check_ssh : 检查MHA的SSH配置。
– masterha_check_repl : 检查MySQL复制。
– masterha_manager : 启动MHA。
– masterha_check_status : 检测当前MHA运行状态。
– masterha_master_monitor : 监测master是否宕机。
– masterha_master_switch : 控制故障转移(自动或手动)。
– masterha_conf_host : 添加或删除配置的server信息。
2)、 Node工具(这些工具通常由MHAManager的脚本触发,无需人手操作)。
– save_binary_logs : 保存和复制master的二进制日志。
– apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它slave。
– filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用这个工具)。
– purge_relay_logs : 清除中继日志(不会阻塞SQL线程)。
3)、自定义扩展：
-secondary_check_script：通过多条网络路由检测master的可用性；
-master_ip_failover_script：更新application使用的masterip；
-shutdown_script：强制关闭master节点；
-report_script：发送报告；
-init_conf_load_script：加载初始配置参数；
-master_ip_online_change-script：更新master节点ip地址；

可基于GTID复制

GTID复制是MySQL 5.6.5复制的一个新特性，GTID事务是全局唯一性的，且一个事务对应一个GTID。一个GTID在一个服务器上只会执行一次，避免重复执行导致数据混乱或者主从不一致。由uuid:trans_id组成，uuid是服务器id，trans_id是事务id。
GTID用来代替传统的复制方法，传统的复制采用binlog和pos开启复制，而GTID不再需要binlog和pos，采用master_auto_position=1来自动匹配GTID断点进行复制。
GTID模式与传统模式的区别：在传统模式里，slave端的binlog可以不用开启；但是GTID模式下slave端的binlog必须开启，目的是记录已经执行过的GTID。

GTID复制流程

1）master更新数据的时候，会在事务前产生GTID，一同记录到binlog日志中。
2）slave端的io线程将binlog写入到本地relay log中。
3）然后SQL线程从relay log中读取GTID，设置gtid_next的值为该gtid，然后对比slave端的binlog是否有记录
4）如果有记录的话，说明该GTID的事务已经运行，slave会忽略
5）如果没有记录的话，slave就会执行该GTID对应的事务，并记录到binlog中