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 的价值在于：

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

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

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

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

不存在"银弹"。

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

关联内容（自动生成）