MySQL 8.0 半同步复制的 commit 超时塌方：sync_timeout、wait_no_slave 与异步回退窗口的取舍

作者江星河-385

MySQL半同步复制分布式一致性复制高可用

结论先行：半同步复制（semi-sync）的“安全”是有时间预算的，超时会静默退化为异步，这个窗口里的丢事务风险，比大家以为的大得多。本文用一次真实事故 + 一组可复现的配置，把 rpl_semi_sync_master_timeout、rpl_semi_sync_master_wait_no_slave、rpl_semi_sync_master_wait_point 三个旋钮的取舍讲清楚。

一、现象：一次 200ms 的复制抖动，换来 17 笔订单“消失”

去年 Q3 压测，我们的订单库（MySQL 8.0.36，单机主 + 两台从，半同步开启）在写入 QPS 约 3800、平均事务 4 行 UPDATE 的场景下，从库因为一次磁盘 IO 抖动（iostat 里 %util 从 35% 冲到 92%，持续 1.8s），apply 速度跟不上主库 commit。

表现非常典型：

主库 SHOW SLAVE STATUS 里 Seconds_Behind_Master 从 0 涨到 2.3s；
业务侧 P99 写延迟从 12ms 飙到 87ms，但没有报错；
事后对账发现，抖动窗口内（约 1.6s）有 17 笔订单在主库 commit 成功、从库未 ack 就丢了，业务侧基于从库读到的状态做了“未下单”判断，导致重复支付 3 笔。

关键点是：主库没有报任何错，事务也正常返回。这就是半同步最反直觉的地方——它退化是静默的。

二、原理：半同步到底“同步”了什么，超时后发生了什么

半同步的核心机制在 commit 路径上：

事务在主库 redo log 落盘后、向 client 返回 ACK 前，会把 binlog 事件发给从库；
从库收到并写入自己的 relay log 后回一个 ACK；
主库等从库 ACK 后才返回成功——注意是“写入 relay log”而不是“apply 完”，这是它和“强一致”的本质区别。

两个关键旋钮决定退化行为：

rpl_semi_sync_master_timeout（单位 ms）：等 ACK 的最长时间。超时后，主库立刻退化为异步复制，把事务返回给 client，丢事务风险从这里产生。默认值是 1000ms（8.0.x），很多人没改过。
rpl_semi_sync_master_wait_no_slave：BOOL。当一台从库都没有时是否还等待（默认 OFF）。OFF 意味着从库全挂的瞬间，所有事务直接异步走，连超时窗口都没有。
rpl_semi_sync_master_wait_point：AFTER_SYNC（默认，binlog 同步后等）/ AFTER_COMMIT（commit 后等）。AFTER_SYNC 是推荐值，性能更好。

还有一个被低估的点：wait_no_slave=OFF + timeout=1000ms 组合下，真正的安全窗口不是 1s，而是 0——只要从库列表为空，立刻异步。这就是为什么“半同步”在很多事故里表现成“异步”。

三、具体做法：配置 + 监控 + 兜底

1) 推荐配置（my.cnf）

[mysqld]
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_wait_point = AFTER_SYNC
# 给从库 apply 留足余量，宁可慢不要丢；线上实测 P99 抖动 300ms 内能收敛
rpl_semi_sync_master_timeout = 3000
# 从库全挂时也要等，逼主库报错而不是静默异步
rpl_semi_sync_master_wait_no_slave = 1
# 允许的最大从库数，防止一个慢从库拖死所有 ack
rpl_semi_sync_master_wait_for_slave_count = 1

wait_for_slave_count = 1 是关键：只要至少 1 台从库 ack 就放行，避免某台慢从库把整条链路拖到超时。

2) 监控：把“退化”变成可观测事件

-- 周期性抓取，退化时立刻告警
SELECT
  VARIABLE_NAME, VARIABLE_VALUE
FROM performance_schema.global_status
WHERE VARIABLE_NAME IN (
  'Rpl_semi_sync_master_clients',   -- 当前半同步从库数，掉到 0 就是危险
  'Rpl_semi_sync_master_timeouts',  -- 累计超时次数，这是核心告警指标
  'Rpl_semi_sync_master_no_tx'
);

告警规则建议：

Rpl_semi_sync_master_timeouts 1 分钟内增量 > 0 → P2 告警；
Rpl_semi_sync_master_clients = 0 持续 5s → P1 告警。

3) 兜底：对账任务

半同步只能保证“主库 commit 成功 = 至少一台从库写了 relay log”，不保证从库 apply 完成。所以对账不能省：

-- 订单表加一个单调递增的 seq，定时对账
SELECT o.id
FROM orders o
LEFT JOIN orders_replica_or o ON o.id = or.id
WHERE o.seq > @last_reconciled_seq
  AND or.id IS NULL;

四、踩过的坑与反直觉之处

wait_no_slave=OFF 是默认值，等于“从库全挂就裸奔”。我们线上就是这个默认值，事故当天从库列表瞬时空了一下，直接走异步。改成 ON 后，主库会直接返回错误，业务侧反而有重试机会。
timeout 不是越大越好。设成 10s 看似安全，实际上会把 P99 写延迟直接拉到 10s，业务超时比丢数据更痛。3s 是我们在“不丢”和“不超时”之间折出来的值。
半同步 ≠ 强一致。它只保证 relay log 落盘，不保证 apply。从库读到的可能是“旧值”，如果你的业务是“写后读”模式，必须走主库读。
AFTER_COMMIT 比 AFTER_SYNC 慢 15–25%（我们压测数据），没有特殊理由不要切。

五、结论与可复用清单

半同步的安全模型是“有时间预算的准同步”，不是“强一致”。三个旋钮的取舍建议：

| 旋钮 | 推荐值 | 理由 | |---|---|---| | rpl_semi_sync_master_timeout | 2000–3000ms | 覆盖 P99 抖动，又不至于拖死业务 | | rpl_semi_sync_master_wait_no_slave | 1 | 从库全挂时逼主库报错，避免静默异步 | | rpl_semi_sync_master_wait_for_slave_count | 1 | 一台 ack 即放行，防止慢从库拖死链路 |

可复用清单：

[ ] 把 Rpl_semi_sync_master_timeouts 纳入核心告警；
[ ] 压测时模拟“从库 IO 抖动”（dd if=/dev/zero of=/tmp/x bs=1M count=2048 或 cgroup 限 IO），观察退化行为；
[ ] 业务侧“写后读”必须走主库；
[ ] 对账任务作为最后一道兜底，不能省；
[ ] 在变更 checklist 里明确：半同步配置变更需要 DBA + SRE 双签。

最后留一个开放问题给大家讨论：如果业务能接受“主库 commit 成功但读不到新值”这种弱一致性，半同步还有必要开吗？还是说直接用异步复制 + 更严格的应用层幂等 + 对账，反而更简单可控？欢迎在评论区聊聊你们线上的取舍。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。