原⽂：百度Mysql数据库⾼可⽤实现⽅案 - 知乎 (zhihu)
数据库⾼可⽤背景
[图⽚上传失败...(image-fea36-1634817091659)]
以上是⼀个典型的mysql主从架构⽅案，分为两个层⾯：
1、数据流量接⼊层，即是mysql的proxy层，它连接mysql的client及后端的server端，它提供的主要功能如下：
sql拦截与修改
性能分析与监控
空气加温器读写分离
请求路由
⾼可⽤问题：
服务器及⽹络异常
接⼊层proxy异常
2、数据库存储层，包括mysql的主库及从库，提供读写服务。 ⾼可⽤问题：
Mysql故障（主库Down、主库假死、主库频繁切换）
⽹络故障
对于流量接⼊层较好处理，探测之后由于多节点等价，可动态切换即可。
数据存储层的异常，原因众多，表征不⼀，难以覆盖完全，同时也容易误判。
这种情况对于⼈⼯恢复是⼀个灾难，同时还要求快速恢复，数据⼀致性及⾼可靠，这就要求有⼀套⾃动化⾼可⽤实施检测⽅案。业内通⽤⽅案
MHA⽅案
image
毒草解毒剂通⽤配置参数说明如下：
MHA 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信息
masterha_stop：关闭MHA
MHA Node
save_binary_logs：保存或复制master的⼆进制⽇志
apply_diff_relay_logs：识别差异的relay log并将差异的event应⽤到其它slave中
v型钢filter_mysqlbinlog：去除不必要的ROLLBACK事件（MHA已不再使⽤这个⼯具）
purge_relay_logs：消除中继⽇志（不会堵塞SQL线程）
MHA流程
image
MHA缺陷
通过select1进⾏主库状态判断，会导致如下问题：
1. 机器及硬盘故障⽆法识别；
2. 连接压⼒太⼤，导致响应问题，会产⽣误识别；
营养块3. 通过ssh拷贝数据，如果硬件故障或者ssh连接问题，⽆法获取最新数据，导致数据延迟或者丢失数据；
4. 由于MHA是中⼼化管理选择主库，主库选择过程中会出现⼀些问题，例如脑裂如何处理？优化架构⽅案
image
Xagent
托管MySQL实例
单点切换
相互通信(通过SSH授权账号)
DBProxy配置管理
普通再生胶配方⽇志切分、清理
Zookeeper
存储：拓扑信息、节点信息
协调: 状态信息
故障识别架构
image
其中ZMaster的功能：
1. 对各proxy间的⽹络故障探测；
2. ⾮硬盘的机器故障探测；
3. Mysql反复故障识别；
4. 中间层组件故障识别。
代理节点：
1. 硬盘故障识别；
2. Mysql故障识别。
故障识别流程
image
结合完整数据库内部识别故障。⾸先收集节点信息以及状态，查看连接数，判断是否是由于 MySQL 实例⾃⾝的压⼒问题或其他问题导致感知DB 有异常的状态，进⽽上升到联合从库的信息检测当前的主库是不是正常。检测感知异常是否是由于假死或压⼒过⼤，然后上升集内部的联合诊治机制。最终上升到整体数据库 APP 检测机制，以此来决策到底要进⾏怎样的切换。同时，在切换时要考虑主从
之间延时的问题。
主从延时处理
半同步复制
Mysql5.6版本的半同步默认是AFTER_COMMIT：
master将每个事务写⼊binlog（sync_binlog=1），传递到slave刷新到磁盘(sync_relay=1)，同时主库提交事务。master等待slave反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。
Mysql5.7的半同步默认是AFTER_SYNC：
master将每个事务写⼊binlog , 传递到slave刷新到磁盘(relay log)。master等待slave反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。
因此5.7引⼊了⽆损复制（after_sync）模式，带来的主要收益是解决after_commit导致的master crash后数据丢失问题，因此在引⼊
after_sync模式后，所有提交的数据已经都被复制，故障切换时数据⼀致性将得到提升。
⽇志数据校验补齐
皮衣加工
基于主库Binlog的同步点校验，将差异值进⾏写⼊到slave进⾏同步。
故障处理流程
image
当在前⾯的识别阶段感知到做的主从切换的时候，百度会在代理层把主库完全替换掉，这个问题在⼀定程度解决切换的过程中出现主库重新写的问题。接下来就是选择主库的过程，当真正拓扑完成后，会将完成信息通过⽹通节点发送⾄代理节点。这⼀选取新主库的过程，就是进⾏故障处理的过程。
脑裂问题
解决的两个层⾯：
1. 单区域内集节点，可通过分布式⼀致性协议，例如RAFT或者Paxos进⾏⾃主选举解决，但是该模式适合较⼩集；
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议