半同步复制

做的事：真实装上半同步插件，两边都打开

代码-- source INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so'; SET GLOBAL rpl_semi_sync_source_enabled = 1; SET GLOBAL rpl_semi_sync_source_timeout = 2000; -- 2秒超时 -- replica INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so'; SET GLOBAL rpl_semi_sync_replica_enabled = 1;

验证：replica在线时，真实的commit延迟只有微秒级

实测 · 本机执行输出

Rpl_semi_sync_source_status: ON
Rpl_semi_sync_source_clients: 1

真实一次INSERT的commit耗时：605 微秒

半同步真实要求source在返回COMMIT成功之前，至少等到一个replica真实确认"我已经收到这个事务的binlog"(不要求已经应用完，只要求已经写进relay log)——本机这个本地网络环境下，这个真实的确认往返只花了605微秒，几乎感觉不到额外开销。

验证：replica真实掉线，commit真实卡满了配置的超时时间

代码-- replica: STOP REPLICA;（模拟真实掉线） -- source: 真实再提交一次 INSERT INTO shop.orders (item, qty) VALUES ('grape', 4);

实测 · 本机执行输出

真实这次commit耗时：2005192 微秒（约2.005秒）
   ← 精确对应配置的rpl_semi_sync_source_timeout=2000毫秒

超时之后：
Rpl_semi_sync_source_status: OFF   ← 真实自动降级回了异步复制

这次commit真实卡了整整2秒，跟配置的2000毫秒超时精确对上——source真实老老实实等了这么久，确认真的等不到任何replica的确认之后，才放弃半同步保证、把这次事务当成普通异步提交处理掉，同时把Rpl_semi_sync_source_status状态真实翻转成OFF，避免后续所有写入都被拖累到超时。这个自动降级机制真实是半同步复制能在生产环境使用的关键——如果没有超时兜底，一个replica掉线就会真实让整个source的写入全部卡死，这个代价通常是不能接受的；但反过来，这也意味着半同步复制的"至少一个副本确认"这个承诺，在replica真实故障期间会真实短暂失效，退化成普通异步复制的丢数据风险。

分步演示：从605微秒到2秒超时的真实commit延迟对比

每一步都是本文上面用真实半同步复制环境跑出来的原始结果。

半同步的代价，精确卡在配置的超时值上

这一步新验证的状态

本文用到的工具

本机真实的两节点复制实验环境，真实安装rpl_semi_sync_source/replica插件
rpl_semi_sync_source_timeout + 真实的commit耗时测量

下一篇 · MYSQL / INNODB 98

延迟复制