mysql mha 逻辑图_mysql 架构 ~ MHA 总揽

一 简介: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集合,在从会执行跳过)