主从复制与高可用 · 复制原理

异步复制、半同步复制、组复制（Group Replication）各自的差异和适用场景？

Differences and use cases of asynchronous replication, semi-synchronous replication, and Group Replication.

答案语言

考察要点

这道题面试官想看你是否深刻理解分布式系统中的核心权衡（Trade-off），尤其是在数据库高可用（High Availability）架构中，数据一致性（Consistency）、性能（Performance）和可用性（Availability） 这三者之间的关系。通过对比不同的复制方案，可以考察你对 MySQL 内核机制的掌握程度，以及在真实业务场景下进行技术选型的能力。

核心概念

MySQL 主从复制的核心是将主库（Master）的二进制日志（Binary Log / Binlog）传输到从库（Slave），并在从库上重放（Apply），从而实现数据同步。三种复制模式的主要区别在于主库在“何时”认为一个事务已经完成。

1. 异步复制（Asynchronous Replication）

这是 MySQL 最早、最基础的复制模式。

工作流程：
1. 主库：用户在主库上执行 COMMIT。主库将事务写入 Binlog，然后立即向客户端返回成功，无需等待任何从库的确认。
2. 传输：主库上的 Binlog Dump 线程异步地将 Binlog 事件发送给从库。
3. 从库：从库的 I/O Thread 接收 Binlog 事件并写入中继日志（Relay Log），然后 SQL Thread 读取 Relay Log 并重放事务。

图示：

text

 1Client --- (1. Txn) ---> Master
 2                           |
 3                           +--- (2. Commit & Write Binlog) --- (3. Respond OK to Client)
 4                           |
 5                           +--- (4. Async Send Binlog) ---> Network ---> Slave

优缺点：
- 优点：性能最高，主库写入延迟最低，因为无需等待网络或从库的响应。
- 缺点：数据一致性最弱。如果主库在提交事务后、但 Binlog 未同步到任何从库之前宕机，那么这部分事务就会永久丢失，造成主从数据不一致。
适用场景：
- 对数据一致性要求不高的场景。
- 读写分离架构中，用于扩展读能力，可以容忍秒级的数据延迟。
- 备份、数据分析等对实时性不敏感的场景。

2. 半同步复制（Semi-synchronous Replication）

为了解决异步复制的数据丢失问题，MySQL 5.5 引入了半同步复制。

工作流程：
1. 主库：用户在主库上执行 COMMIT。主库将事务写入 Binlog。
2. 等待确认：主库将 Binlog 事件发送给从库，然后阻塞，等待至少一个从库返回 ACK（Acknowledge），确认已接收到 Binlog 事件并写入其 Relay Log。
3. 返回成功：主库收到 ACK 后，才向客户端返回成功。
4. 超时降级：如果主库在指定超时时间（rpl_semi_sync_master_timeout）内未收到 ACK，会自动降级为异步复制，以保证主库的可用性。

图示：

text

 1Client --- (1. Txn) ---> Master
 2                           |
 3                           +--- (2. Write Binlog & Send) ---> Network ---> Slave
 4                           |                                                 |
 5                           (4. Receive ACK) <--- (3. Write Relay Log & Send ACK) <---+
 6                           |
 7                           +--- (5. Respond OK to Client)

版本差异（关键）：
- AFTER_COMMIT (MySQL 5.5+)：主库在 InnoDB 存储引擎层提交事务之后，再等待从库的 ACK。这存在一个极小的时间窗口：如果在主库 COMMIT 后、收到从库 ACK 前主库宕机，事务在主库上已持久化，但从库可能还未收到，主备切换后该事务丢失。
- AFTER_SYNC (无损复制，MySQL 5.7+)：主库将事务写入 Binlog 并同步（fsync）到磁盘后，等待从库 ACK，收到 ACK 之后，才在 InnoDB 存储引擎层提交事务。这保证了只要客户端收到成功，数据就一定存在于至少两个节点（主库 Binlog 和至少一个从库 Relay Log），极大降低了数据丢失风险。
优缺点：
- 优点：大大提高了数据一致性，有效防止了主库宕机导致的数据丢失。
- 缺点：增加了主库的写入延迟（至少一个网络来回 RTT）。在网络不佳或从库繁忙时，会影响主库性能。
适用场景：
- 对数据一致性要求较高的核心业务，如交易、订单系统。
- 绝大多数要求高可用的生产环境的标准配置。

3. 组复制（MySQL Group Replication, MGR）

MGR 是 MySQL 5.7.17 引入的、基于 Paxos 协议变体的、实现数据强一致性的高可用方案。

工作流程：
1. 成员组：多个 MySQL 服务器组成一个复制组（Group）。
2. 广播事务：客户端在一个节点（主节点）上发起事务。该节点在提交前，会将事务（写集）广播给组内所有成员。
3. 认证与共识：组内所有成员对该事务进行认证（Certification），检查是否存在冲突。基于 Paxos 协议达成共识，大多数节点同意后，事务才能在所有成员上提交。
4. 全局提交：一旦达成共识，组内所有成员都会以相同的顺序提交该事务。

图示 (Mermaid):

mermaid

 1graph TD
 2    Client --> NodeA[Member A]
 3    subgraph Group
 4        NodeA -- 1. Broadcast Tx --> NodeB[Member B]
 5        NodeA -- 1. Broadcast Tx --> NodeC[Member C]
 6        NodeB -- 2. Certify & Vote --> NodeA
 7        NodeC -- 2. Certify & Vote --> NodeA
 8        NodeA -- 3. Majority OK? --> NodeA
 9    end
10    NodeA -- 4. Commit & Respond --> Client

模式：
- 单主模式（Single-Primary）：只有一个节点可写，其他节点只读。当主节点故障时，组内会自动选举出新主，实现自动故障转移。
- 多主模式（Multi-Primary）：所有节点都可读写。对写入性能有帮助，但要求业务能处理多点写入带来的冲突问题（如使用自增ID可能冲突），对应用设计有更高要求。
优缺点：
- 优点：数据强一致性，无数据丢失风险（只要大多数节点存活）。内置自动故障检测和故障转移，可用性高。
- 缺点：性能开销最大，写操作需要经过组成员的共识，延迟较高。对网络质量要求极高，不适合跨地域部署。
适用场景：
- 金融级、对数据一致性要求零容忍的场景。
- 需要全自动故障转移、减少运维介入的业务。

常见低分回答

混淆半同步的“接收”与“应用”：错误地认为“半同步是等从库把事务执行完才返回”。实际上，半同步只等待从库将 Binlog 写入 Relay Log，并不等待 SQL Thread 执行。
认为半同步是绝对无损的：忽略了 AFTER_COMMIT 模式下的微小数据丢失风险，以及超时会降级为异步复制这一关键机制。高分回答必须能区分 AFTER_COMMIT 和 AFTER_SYNC。
将组复制简单理解为“多主复制”：组复制的核心是基于 Paxos 的共识协议，保证数据强一致性。“多主”只是其一种运行模式，单主模式更为常用和稳定。其本质是分布式一致性协议的实现。
忽略性能开销：只谈一致性优点，不谈延迟和吞吐量上的巨大差异。例如，声称所有场景都应该用组复制，这在实践中是不可行的。
对超时降级机制不了解：不清楚半同步在从库异常时会退化为异步，这会给系统带来短暂的数据丢失风险，是监控和告警的重点。

工程实践与优化

架构选型对比：

特性	异步复制	半同步复制 (`AFTER_SYNC`)	组复制 (MGR)
数据一致性	弱（可能丢数据）	较强（极低概率丢数据）	强（不丢数据）
主库写延迟	最低	中等（增加 1 RTT）	最高（共识协议开销）
故障转移	手动 / 脚本	手动 / 脚本	自动
架构复杂度	低	中	高
网络依赖	低	中	高
适用场景	读扩展、非核心业务	核心 `OLTP` 业务	金融级、核心支付业务

执行计划与监控：
- 复制性能不直接体现在 EXPLAIN 中，但主库的慢查询会直接导致复制延迟。
- 核心监控指标：
  - Seconds_Behind_Master：衡量从库数据延迟的关键指标。
  - SHOW SLAVE STATUS \G：查看 Slave_IO_Running 和 Slave_SQL_Running 状态。
  - 半同步状态：SHOW GLOBAL STATUS LIKE 'Rpl_semi_sync_master_status' (ON/OFF) 和 Rpl_semi_sync_master_clients (连接的半同步从库数)。
  - MGR 状态：查询 performance_schema.replication_group_members 表，检查各成员的 MEMBER_STATE (ONLINE/RECOVERING/ERROR)。
实践中的坑：
- 半同步超时设置：rpl_semi_sync_master_timeout 设置过短，网络稍有波动就降级为异步；设置过长，从库故障时主库会长时间阻塞。通常设置为 1-3 秒。
- MGR 网络分区（脑裂）：MGR 依赖稳定的网络。网络分区可能导致组分裂，一部分节点会进入 ERROR 状态并被隔离，以保证数据一致性。
- 混合部署：常见的健壮架构是：核心交易库使用 3 节点的 MGR 集群保证数据一致性和自动 failover，然后从 MGR 集群中异步拉取数据到多个只读实例，用于报表和查询，兼顾一致性与性能。

常见追问与延伸题目

追问：如果让你在半同步和 MGR 之间做选择，你的决策依据是什么？
- 回答要点 1 (业务需求)：首先看业务对 RPO (Recovery Point Objective，数据丢失容忍度) 的要求。如果 RPO=0，即完全不能丢失任何一笔已提交的事务，那么 MGR 是唯一选择。如果可以容忍极低概率（如主备同时宕机）的数据丢失，半同步复制是更具性价比的方案。
- 回答要点 2 (性能与成本)：评估业务对写延迟的敏感度。MGR 的写延迟显著高于半同步，对于高并发、低延迟的写入场景可能是瓶颈。同时，MGR 对硬件和网络的要求更高，运维复杂度也更高，需要评估团队的技术储备和成本。
- 回答要点 3 (可用性需求)：如果需要全自动的故障转移能力，减少半夜人工介入，MGR 的价值就非常大。而半同步通常需要配合 MHA、Orchestrator 等第三方工具才能实现自动 failover。
追问：GTID（全局事务标识符）在这些复制方案中扮演什么角色？为什么现在都推荐使用？
- 回答要点 1 (简化故障转移)：GTID 为每个事务分配一个全局唯一的 ID（source_id:transaction_id）。在主备切换时，新主库知道旧主库执行到了哪个 GTID，新从库可以自动从新主库找到正确的复制位点，无需像传统基于文件和位置点（file:pos）那样手动定位，极大简化了 failover 过程，降低了出错风险。
- 回答要点 2 (MGR 的基础)：MGR 强制要求开启 GTID。因为 MGR 需要在组内所有成员间同步和认证事务，GTID 是追踪和识别这些事务的唯一方式。
- 回答要点 3 (简化集群拓扑)：有了 GTID，可以轻松地搭建更复杂的复制拓扑，如一主多从、级联复制，或者从一个从库再搭建一个新的从库，都不再需要复杂的 CHANGE MASTER 操作。
追问：这些和 PostgreSQL 的复制或 TiDB/OceanBase 这类分布式数据库有什么本质区别？
- 回答要点 1 (PostgreSQL 对比)：PostgreSQL 的流复制（Streaming Replication）在概念上与 MySQL 类似。其异步流复制对应 MySQL 异步复制。其同步复制（synchronous_commit）可以配置为等待任意 N 个备库确认，功能上比 MySQL 半同步更灵活，可以实现类似“至少 N 个节点确认”的逻辑，但其底层仍是主-备模式，不是基于 Paxos/Raft 的共识。
- 回答要点 2 (NewSQL 数据库对比)：TiDB、OceanBase、CockroachDB 这类分布式数据库（NewSQL）在架构上是根本性的不同。它们是基于 Raft（一种与 Paxos 等价的共识算法）构建的。数据被切分成 Region/Partition，每个 Region 的多个副本（Replica）构成一个 Raft Group。写入操作必须经过 Raft Group 内大多数副本的共识才能提交。因此，数据复制和强一致性是其与生俱来的核心能力，而不是像 MySQL 那样是外挂的模块。它们的架构天然就是多活、无单点故障，并且能水平扩展。而 MySQL 的复制方案本质上还是在修补单体架构的可用性和一致性问题。