Mysql主从同步、延迟、半同步、脑裂速览
Eddie一、MySQL主从同步核心原理
1. 架构角色
-
主库（Master）：负责承接所有写操作（INSERT/UPDATE/DELETE），记录数据变更日志
-
从库（Slave）：同步主库数据，承接项目读请求，实现读写分离
2. 完整同步流程
-
主库执行事务写操作，事务提交时，将数据变更记录写入binlog（二进制日志）；
-
从库启动独立的 IO线程，主动建立与主库的连接，持续拉取主库binlog日志；
-
主库接收从库请求，推送最新的binlog日志数据；
-
从库IO线程将拉取到的日志，持久化到本地 relay log（中继日志）；
-
从库启动独立的 SQL线程，读取本地中继日志，复刻执行SQL语句，完成数据同步。
3. 核心作用
-
实现读写分离，分摊主库压力，提升数据库查询性能
-
实现数据冗余备份，提升数据库整体可用性
二、主从延迟成因与解决方案
主从延迟指：主库数据写入完成后，从库未及时同步数据，短时间内主从数据不一致，业务可能查询到旧数据。
1. 核心成因
-
线程模型差异：主库支持多线程并发写入，旧版本从库仅单线程重放日志，无法匹配主库并发速度
-
大事务/长事务：主库单次事务批量更新大量数据，从库重放耗时久，造成延迟堆积
-
从库性能瓶颈：从库CPU、内存、磁盘配置低于主库，或从库承接大量复杂慢查询、存在锁等待，占用同步线程资源
-
网络问题：主从服务器带宽不足、网络波动，导致binlog传输缓慢
-
DDL操作阻塞：主库执行表结构变更，从库同步执行时会阻塞后续所有同步操作
2. 通用解决方案
-
开启并行复制（最优方案）：将从库单线程重放改为多线程并发重放，大幅缩小同步时差
-
优化事务设计：拆分超大事务，避免长事务，减少单次同步压力
-
规范从库使用：从库仅承担读查询，禁止写入、禁止执行复杂统计、大批量查询SQL
-
提升硬件配置：对齐主从服务器硬件性能，消除机器性能瓶颈
-
实时监控告警：通过
Seconds_Behind_Master监控主从延迟，异常及时处理
三、半同步复制
1. 基础概念
MySQL默认主从为异步复制：主库提交事务后直接返回客户端成功，无需等待从库同步日志。若主库提交后瞬间宕机，binlog未同步至从库，会造成数据丢失。
半同步复制是对异步复制的优化方案。
2. 执行机制
主库事务提交后，不会立即返回成功，需等待至少一台从库接收binlog并返回ACK确认后，再响应客户端事务提交成功。
3. 优缺点
-
优点：极大降低主库宕机导致的数据丢失风险，提升数据安全性
-
缺点：增加一次网络交互开销，轻微降低数据库写入性能
四、并行复制
1. 解决问题
针对旧版本从库单SQL线程重放日志，无法跟上主库并发写入速度，导致主从延迟过高的问题。
2. 核心原理
将从库单一的日志重放线程，改造为多线程并发重放，并行复刻主库数据变更。
3. 主流模式
-
按库并行、按表并行
-
按提交组并行（MySQL5.7+ 最优）：同一时间段内提交的独立事务，可并行重放，同步效率最高
五、主从切换与脑裂问题
1. 什么是主从切换
当原有主库宕机、断电、故障或需要停机维护时，为保证业务正常写入，会将集群中一台健康的从库提升为新主库，承接业务写流量，该过程即为主从切换。
注意：MySQL原生不支持自动主从切换，需依赖第三方组件（MHA、ShardingSphere、MGR）实现。
2. 什么是脑裂
主从集群网络波动、断连时，监控组件误判原有主库宕机，将从库提升为新主库；但旧主库实际正常运行，仍可承接写入。最终集群出现新旧双主同时写入，导致数据分裂、错乱、无法合并，该问题即为脑裂。
3. 脑裂解决方案
-
旧主隔离机制：主从切换前，通过漂移VIP、封禁端口、停止服务等方式，强制下线旧主，杜绝双主共存
-
过半选举机制：基于Raft/Paxos一致性协议，必须超过半数节点确认，才可执行主库切换
-
只读约束：常态下所有从库开启只读模式，避免误写入
-
官方集群方案：使用MySQL MGR组复制，内置一致性协议，原生防脑裂
六、ShardingSphere 与主从高可用（重点）
1. 核心定位
ShardingSphere属于流量路由层中间件，而非数据库底层高可用组件。不负责MySQL主从复制、日志同步、节点选举。
核心能力：实现数据库读写分离、故障探活、流量自动切换。
2. 防脑裂能力
-
单独使用ShardingSphere 无法彻底防止脑裂
-
搭配注册中心（ZooKeeper/Etcd，基于Raft协议），依靠临时节点、分布式锁、过半校验机制，可大幅降低脑裂概率
-
生产最优方案：ShardingSphere（流量路由）+ MGR（底层强一致集群）
七、总结
-
主从同步：主库记录binlog，从库IO线程拉取日志写入中继日志，SQL线程重放实现数据同步
-
主从延迟：主库并发写入、从库单线程重放、大事务、硬件与网络问题导致
-
优化方案：拆分大事务、开启并行复制、从库只读、优化硬件与SQL
-
半同步复制：主库等待从库ACK确认后再返回，解决异步复制数据丢失问题
-
脑裂：网络异常导致双主共存，通过隔离旧主、过半选举、MGR集群解决