after_sync 不等于强一致性，因为它仅保证主库提交前至少一个从库已写入 relay log，但不确保从库执行事务、不防主库崩溃丢数据、不解决网络分区降级问题；它只是比异步更安全的折中方案。

MySQL 半同步复制没有强一致性模式。它只能保证“至少一个从库已写入 relay log”，不承诺事务执行、不防主库崩溃丢数据、也不解决延迟或脑裂问题。真要强一致性，得上 Group Replication 或 InnoDB Cluster。

为什么 AFTER_SYNC 不等于强一致

AFTER_SYNC 是 MySQL 5.7 唯一能接近“无损”的 wait_point，但它只控制主库提交前是否等待从库落盘（relay log），不控制： - 从库 SQL 线程是否已执行该事务（Seconds_Behind_Master 可能仍 > 0） - 主库 crash 后 binlog 是否已 fsync 到磁盘（依赖 sync_binlog=1 和 innodb_flush_log_at_trx_commit=1） - 网络分区时主库是否自动降级（rpl_semi_sync_master_timeout 触发后立刻变异步）

也就是说：AFTER_SYNC 降低丢失概率，但不消除风险。生产环境里，它只是“比异步好一点”的折中选择。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

主库必须设对的三个参数

- rpl_semi_sync_master_enabled = 1：启用插件（仅开关，不够） - rpl_semi_sync_master_wait_point = 'AFTER_SYNC'：必须显式设，不能用默认 AFTER_COMMIT（后者在主库 crash 时仍可能丢事务） - rpl_semi_sync_master_timeout = 3000：单位毫秒，设 10000 容易卡住业务，设 100 会导致频繁降级；3000～5000 是较稳的平衡点

这三个参数缺一不可。只开 enabled 而不设 wait_point，等于白配。

从库重启 I/O 线程是硬性要求

装完 rpl_semi_sync_slave 插件后，光执行 SET GLOBAL rpl_semi_sync_slave_enabled = 1 不生效。 - 必须立刻执行：STOP SLAVE IO_THREAD; START SLAVE IO_THREAD; - START SLAVE 不行，它只重启 SQL 线程，I/O 线程不重连就不会建立 ACK 通道 - 验证是否成功：SHOW STATUS LIKE 'Rpl_semi_sync_slave_status'; 返回 ON 才算真正启用

容易被忽略的底层依赖

半同步不是独立机制，它完全依赖异步复制底座： - 主库 log_bin 必须开启，且 binlog_format = ROW（推荐） - 从库 server_id 唯一，log_slave_updates = 1（尤其当有级联场景） - 禁用 binlog-do-db / replicate-ignore-db ——这类过滤规则会干扰 GTID 和 ACK 触发逻辑 - SHOW SLAVE STATUS\G 中 Slave_IO_Running 和 Slave_SQL_Running 必须都是 Yes，且 Seconds_Behind_Master 稳定趋近于 0

任何一项不稳，半同步就形同虚设——它不会报错，只会悄悄降级为异步，你根本不知道。