全同步复制:最安全但最慢的复制方式

全同步复制:最安全但最慢的复制方式

概述

全同步复制(Full Synchronous Replication)是所有复制模式中最严格的一种:主库提交事务时,必须等待所有从库都应用了该事务,才返回客户端成功。 这是数据安全的最高等级,但也是性能最差的复制方式。

全同步复制的工作流程

主库                                 从库 1          从库 2
  │                                    │               │
  │── 1. 事务提交                     │               │
  │   ├── 写入 Binlog                 │               │
  │   └── 等待中...                   │               │
  │                                    │               │
  │── 2. 发送 Binlog                  │               │
  │   ├── 发送给从库 1               │               │
  │   └── 发送给从库 2 ──────────────→               │
  │                                    │               │
  │                      3. 从库 1 收到并应用 ✅────│
  │                                    │               │
  │                      4. 从库 2 收到并应用 ✅─────
  │                                    │               │
  │── 5. 所有从库已确认              │               │
  │   ├── 全部节点数据一致 ✅        │               │
  │   └── 返回客户端成功 ✅          │               │

关键点:所有从库不仅要收到 Binlog,还要应用完成,主库才返回成功。

MySQL 中的全同步复制

MySQL 原生不支持真正的全同步复制

MySQL 中没有原生实现真正的全同步复制。最接近的是:

  1. 半同步复制 + 多个从库:设置为等待所有从库确认,但只确认”收到”而非”应用”
  2. MGR 多主模式:所有节点确认事务,但也是基于 Paxos 的多数确认,不是全部
  3. MySQL Cluster(NDB):真正的全同步,但这是完全不同的架构

NDB Cluster 的全同步

MySQL NDB Cluster 实现了真正的全同步:

-- NDB 引擎使用全同步复制
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100)
) ENGINE=NDB;

在 NDB 中,数据分片存储到多个数据节点,每个分片有多个副本:

用户写入 → NDB API 节点
    │
    ├── 写入分片 1 的所有副本
    │   ├── 数据节点 A ✅
    │   └── 数据节点 B ✅
    │
    ├── 写入分片 2 的所有副本
    │   ├── 数据节点 C ✅
    │   └── 数据节点 D ✅
    │
    └── 所有副本确认后才返回成功

NDB 是内存数据库,全同步的代价比 InnoDB 小很多。

全同步复制的优缺点

优点

优点 说明
零数据丢失 任何一个节点崩溃,数据不会丢
强一致性 所有节点数据完全一致
读任意节点 从任意节点读取都立即看到最新数据
故障切换无风险 切换到任何节点都不会丢数据

缺点

缺点 说明
性能极差 写入延迟 = N 倍网络往返 + N 倍磁盘写入
可用性降低 任何一个慢节点拖慢整个集群
节点越多越慢 写入延迟与从库数量成正比
网络要求极高 不能有任何抖动
应用受限 不适用于高并发写入场景

性能对比

写入延迟

场景:3 个节点,网络延迟 0.5ms

异步复制:
写入延迟 = 磁盘写入 ≈ 0.1ms
总延迟 ≈ 0.1ms

半同步复制(1 个从库确认):
写入延迟 = 磁盘写入 + 网络往返 1 次 ≈ 0.1ms + 0.5ms = 0.6ms

全同步复制(所有从库确认+应用):
写入延迟 = 磁盘写入 + 2 次网络往返 + 2 次从库应用
         ≈ 0.1ms + 1.0ms + 1.0ms = 2.1ms

可用性

节点数 全同步可容忍故障 MGR 可容忍故障
3 0 个(任何节点慢就整体慢) 1 个
5 0 个 2 个
7 0 个 3 个

使用场景

场景 是否适合 原因
金融核心交易 ⚠️ 需权衡 数据安全要求极高,但可用性也很重要
跨机房部署 ❌ 不适合 跨机房延迟高,全同步不可用
配置/元数据系统 ✅ 少量数据 数据量小且一致性要求极高
分布式锁/选举 ✅ 合适 数据量小,一致性高于性能
高并发写入 ❌ 不适合 性能无法满足

面试要点

  1. MySQL 没有原生的全同步复制,最接近的是 MGR 或半同步 + 所有从库确认
  2. NDB Cluster 是真正的全同步,但 NDB 是内存引擎,架构不同
  3. 全同步的代价:写入延迟与节点数成正比,任何一个慢节点拖慢所有写入
  4. 全同步 vs 性能:数据一致性和写入性能是一个永恒的矛盾,两者只能取其一
  5. 生产环境中不推荐”全同步”,更常用的是半同步复制(主库确认收到就行,不等应用)
  6. “强一致性”≠全同步——MGR 使用 Paxos 协议,多数节点确认即可,这也是平衡方案
© 版权声明
THE END
喜欢就支持一下吧
点赞10 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容