MySQL 复制系统

一、复制系统要解决的本质问题

复制不是为了"多一份数据"，而是为了解决以下系统性约束：

  1. **状态扩散问题**：如何将一个节点上的数据变更，可靠地扩散到其他节点
  2. **读写压力分摊**：写集中、读扩散的资源不对称问题
  3. **故障与不确定性**：节点失效、网络抖动、进程崩溃
  4. **一致性与可用性的权衡**：CAP 不可兼得

因此，复制系统的目标不是"零延迟"，而是：在可控成本下，提供可预期的一致性与可恢复能力。

二、复制系统的通用抽象模型（原理层）

任何数据库复制系统，都可以抽象为以下五个稳定模块：

数据变更捕获      ↓变更传输      ↓变更缓冲      ↓变更重放      ↓一致性约束与治理反馈
抽象模块核心问题MySQL 实现
变更捕获如何感知状态变化binlog
变更传输如何可靠传递IO Thread
变更缓冲如何削峰填谷relay log
变更重放如何应用变更SQL / worker
一致性约束如何避免冲突GTID / writeset

该模型独立于 MySQL，适用于 PostgreSQL、Oracle、CDC、消息复制系统。

三、MySQL 主从复制机制（实现层）

3.1 基本工作流

该设计的核心思想是：

获取（IO）与重放（SQL）解耦，以提升系统鲁棒性

代价是：

四、复制语义与一致性模型

4.1 复制不是一致性保证

复制语义本质含义风险
异步复制主库提交即返回数据丢失
半同步复制至少一个备库确认写延迟
同步复制多副本同时提交吞吐下降

MySQL 的半同步复制，是在：

五、复制格式：描述"变更"还是"结果"

模式描述对象本质
Statement操作意图可解释但不确定
Row最终结果确定但成本高
Mixed风险感知切换工程权衡

从系统角度看：Row 模式本质是 事件溯源（Event Sourcing） 的一种实现。

六、并行复制：吞吐优化的边界

6.1 为什么并行受限

并行复制必须满足两个不变约束：

  1. 同一行的更新不能并行（避免写覆盖）
  2. 一个事务不能被拆分

这不是 MySQL 的限制，而是：

状态机复制的一般性约束

6.2 MySQL 的并行策略

本质是：

通过冲突检测，最大化可并行子图

七、复制拓扑：结构决定风险

7.1 常见拓扑的系统含义

拓扑优点隐含风险
一主多备简单清晰主库瓶颈
级联复制扩展读延迟放大
主主复制高可用冲突复杂度
环形复制去中心化失控风险

拓扑不是连线问题，而是 因果链路设计问题。

八、复制治理：控制论视角

复制系统必须被"调控"，而不是"放任"。

8.1 治理闭环模型

  1. **观测**：延迟、一致性、错误
  2. **判定**：是否可接受
  3. **干预**：限流、切换、重建
  4. **反馈**：参数与架构调整

8.2 核心治理指标

九、主备切换：可靠性 vs 可用性

两种本质策略：

策略优先级代价
等待追平一致性停写
直接切换可用性不一致

这不是技术问题，而是：

业务对 CAP 的选择

GTID 的价值在于：

十、读写分离：一致性外溢

读写分离的复杂性，来自一个事实：

复制延迟被暴露给了应用层

常见解决方案，本质都是：

不存在"银弹"。

十一、认知总结（稳定结论）

关联内容（自动生成）