一 简介:MHA相关
二 切换流程
0 主库已不可达
阶段一
1 从集群选出新主,根据新主同步的binlog信息进行拷贝binlog到MHA管理机上
阶段二
0 确保新主已应用完剩余全部relay-log
1 set sql_log_bin =0
2 新主应用补全日志
3 绑定VIP打开读和写
阶段三
1 从库并行恢复数据,应用的日志就是当时新主应用包含的binlog(master补偿)/relay log event(slave补偿),这里的binlog是通过ssh远程应用,所以必须做 SSH免密登录
2 从库重新指向新主
阶段四
1 新主清除复制信息
三 注意点
1 防脑裂配置
perl切换脚本增加aprping vip命令,可以防止出现脑裂问题,如果存在就不进行VIP的新绑定
2 从库延时情况
MHA当选择新主时,会等待新主应用完之前的relay-log,不会立刻切换,所以尽量减少从库延时情况,以免从库不可用,为什么会等待呢 因为获取master补偿日志的位置是 read_master_postion,如果不等待直接应用,肯定会导致数据错乱
两部分数据 1 新主本身没有应用完的relay-log 2 旧主拷贝来的binlog
3 第二检测脚本
了确保网络问题,会根据第二检测脚本从从库发起动作,确保不是单点网络问题,强烈推荐配置
4 不要添加指定新主参数
当指定新主参数时,当新主数据缺少时,会向其他从库寻求数据补偿,然后才会采用旧主的binlog补偿.如果其他从库的relay-log丢失,那么新主的数据应该也是缺少的
5 关于relay-log的管理
尽量不要自动删除relay-log,添加计划任务,定时对relay-log进行清理,保证有数据补偿的来源
四 GTID模式的相关问题
1 GTID模式下必须配置binlog_server,因为会根据此参数配置是否采用主库补全措施
2 binlog_server有几大特点
1 binlog_server 可以配置多个源
2 binlog_server 可以指派到master的binlog目录(妥协解决方式,和传统复制没有区别),记住 当进行切换之后必须将binlog_server指向新主,防止发生问题
3 binlog_server 建议在从库或者其他服务器建立服务(推荐后者)
4 binlog_server 建立的目的是为了当主库down机而slave的IO_THREAD出现延迟没有接收到主库的binlog场景下,相比较而言 binlog_server的压力远远小于io_thread
(其实这种场景比较少见,常见于主库频繁生成binlog信息导致网络流量卡死的情况)
3 GTID+增强半同步复制
1 这种架构能避免 因为增强半同步转化成异步复制发生故障时的场景
2 不用自己脚本,MHA能实现选新主和VIP漂移,增强半同步可以保证数据不丢(如果强制增强半同步情况下)
3 GTID和传统复制 MHA拷贝binlog和补偿数据采用的是两套不同的逻辑方案
五 补充
1 采用MHA+普通复制的场景下,MHA不会出现丢数据的问题,所以上面要标注GTID环境下
2 如果不采用MHA,可以试试Orchestrator
3 MHA当新master无问题时1 生成change语句 2 绑定VIP 3 打开读写,后续才会进行slave的日志补偿(包括切换前缺少的relay和切换后的补偿binlog),这也符合服务可用的设计规则
GTID模式下会自动寻找新主的最初日志 非GTID模式直接应用change语句 (对于中继日志的情况MHA会记录本身执行的GTID_executed集合,在从会执行跳过)