目录
个人原创总结之 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中