MySQL半同步复制：原理、优劣与高可用场景解析

在聊 MySQL 主从复制 时，大多数人只停留在：

• 异步复制（Asynchronous）
• GTID
• 主从延迟

但在 数据安全 和 高可用 场景下，有一个非常关键却常被忽略的机制：

半同步复制（Semi-Synchronous Replication）

它正好站在 性能 和 数据安全 的中间点。

一、先说结论：什么是半同步复制？

半同步复制 是一种介于 异步复制 和 全同步复制 之间的复制模式：

主库在事务提交时，至少要等一个从库确认“已接收到 binlog”，才算提交成功。

注意关键词：

• ✔ 不是等从库执行完成
• ✔ 只等从库“收到 binlog”
• ✔ 至少一个从库

二、为什么需要半同步复制？

先看最常见的 异步复制 问题。

❌ 异步复制的致命风险

异步复制流程是：

主库提交事务
→ 返回成功
→ 从库异步拉 binlog

如果此时：

• 主库宕机
• binlog 还没传到从库

👉 数据直接丢失（主从切换后无法找回）

这在以下场景非常危险：

• 交易系统
• 订单系统
• 金融、支付业务

三、半同步复制是如何工作的？（核心原理）

半同步复制在异步复制的基础上，多了一步 ACK 确认机制。

半同步复制流程

1. 主库执行事务
2. 写 binlog
3. 发送 binlog 给从库
4. 至少一个从库返回 ACK（确认收到）
5. 主库提交事务并返回成功

📌 注意：

• 从库 不需要执行完成
• 只需要 写入 relay log

四、半同步 vs 异步 vs 全同步（重点对比）

复制模式	主库是否等待从库	数据安全性	性能
异步复制	❌ 不等待	❌ 可能丢数据	⭐⭐⭐⭐⭐
半同步复制	✅ 等 1 个 ACK	⭐⭐⭐⭐	⭐⭐⭐⭐
全同步复制	✅ 等所有从库执行	⭐⭐⭐⭐⭐	⭐

一句话总结：

半同步 = 用一点性能，换大量数据安全

五、半同步复制解决了什么问题？

✅ 1️⃣ 大幅降低数据丢失风险

只要有一个从库收到 binlog：

• 主库宕机
• 从库仍然保有最新事务

👉 主从切换不会丢数据

✅ 2️⃣ 非常适合主库单点故障场景

半同步复制是以下方案的“标配”：

• 主从 + VIP
• MHA
• Orchestrator

✅ 3️⃣ 性能损耗可控

因为：

• 不等从库执行
• 只等网络传输 + IO 写入

一般延迟在 毫秒级

六、半同步复制的缺点（必须知道）

❌ 1️⃣ 性能一定比异步差

• 每个事务多一次网络往返
• 写延迟略有增加

❌ 2️⃣ 从库异常会影响主库

如果：

• 所有从库不可达
• ACK 超时

主库会：

• 等待超时
• 自动退化为异步复制

❌ 3️⃣ 并不能解决复制延迟

半同步只保证：

binlog 被接收

但：

• 从库执行慢
• 大事务

👉 延迟仍然可能存在

七、半同步复制的“自动降级机制”（很重要）

MySQL 的半同步不是“死等”。

如果：

• 在指定时间内（默认 10s）
• 没有收到任何从库 ACK

主库会：

自动切换回异步复制

等从库恢复，再重新启用半同步。

📌 这保证了：

• 可用性优先
• 不会无限阻塞主库

八、如何开启半同步复制？（简单了解）

1️⃣ 主库 & 从库安装插件

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

2️⃣ 开启半同步参数

主库：

SET GLOBAL rpl_semi_sync_master_enabled = ON;

从库：

SET GLOBAL rpl_semi_sync_slave_enabled = ON;

3️⃣ 验证状态

SHOW STATUS LIKE 'Rpl_semi_sync%';

九、半同步复制适合什么场景？

✅ 适合：

• 核心交易系统
• 订单 / 支付系统
• 对数据丢失极其敏感的业务
• 主从架构 + 自动切换（常用于保障高可用）

❌ 不适合：

• 超高写入 QPS 场景
• 对写延迟极度敏感的系统
• 单从库、网络不稳定环境

十、面试高频问题总结（直接背）

Q1：半同步是强一致吗？

❌ 不是
它只保证 binlog 不丢，不保证从库立刻可读。

Q2：半同步会不会导致主库卡死？

❌ 不会
有超时和自动降级机制。

Q3：生产一定要用半同步吗？

👉 核心业务强烈建议
👉 非核心业务可异步

十一、30 秒总结版

MySQL 半同步复制是一种介于异步和全同步之间的复制模式。
主库在事务提交时，至少等待一个从库确认接收到 binlog，才返回成功，从而大幅降低主库宕机导致的数据丢失风险。
它牺牲少量性能，换取更高的数据安全性，非常适合核心业务场景。

如果你正在设计或维护一个对数据一致性要求较高的MySQL数据库架构，理解并合理应用半同步复制机制至关重要。想了解更多数据库高可用与实践经验，欢迎访问云栈社区与其他开发者交流探讨。