半同步复制不能防止主从切换时的事务丢失，真正防丢需“选对从库”+“主库日志落盘可靠”；必须同时配置sync_binlog=1、innodb_flush_log_at_trx_commit=1和rpl_semi_sync_master_timeout=10000，并验证read_master_log_pos==exec_master_log_pos及sql线程执行完毕。
半同步复制不能防止主从切换时的事务丢失，只能降低概率；真正防丢的关键是“选对从库”+“主库自身日志落盘可靠”，配置开关只是第一步。
为什么开了半同步还是丢数据
常见错误是以为 rpl_semi_sync_master_enabled=ON 就万事大吉。实际上半同步只保证至少一个从库收到了 binlog 并写入 relay log（不保证已执行、不保证已提交）。若主库 crash 后，选中的是那个“收到但没来得及执行”的从库做新主，未执行的事务就永久丢失了。
-
Rpl_semi_sync_master_no_tx非零说明已退化为异步——不是配置没生效，是超时后自动 fallback - 错误日志里出现
Timeout waiting for reply from slave是退化的直接证据 -
SHOW SLAVE STATUS\G中Read_Master_Log_Pos和Exec_Master_Log_Pos差距大，说明 SQL 线程严重滞后，半同步形同虚设
必须同时启用的三个核心参数
半同步只是“传输链路保险”，主库自身不把日志刷盘，照样丢数据。以下三项必须共存：
-
sync_binlog = 1：每次事务提交都强制刷 binlog 到磁盘，否则主库宕机后未刷盘的 binlog 永久消失 -
innodb_flush_log_at_trx_commit = 1：每次事务提交都刷 redo log 到磁盘，保障 InnoDB 层不丢已提交事务 -
rpl_semi_sync_master_timeout = 10000：设为 10 秒，太短（如 1000）会导致网络抖动时频繁退化，太长（如 60000）会让主库响应卡顿
注意：server_id 必须全局唯一，且从库需运行 START SLAVE IO_THREAD（半同步依赖 IO 线程上报 ACK）。
切主前必须验证的两个状态
人工或工具切换前，仅看 Seconds_Behind_Master = 0 不够。必须确认：
-
Slave_SQL_Running_State显示Slave has read all relay log，而非Reading event from the relay log -
Read_Master_Log_Pos == Exec_Master_Log_Pos，表示从库不仅拉到了最新位点，而且已全部执行完毕 - 用
mysqlbinlog对比主库最新 binlog position 和从库Read_Master_Log_Pos，差太多说明 IO 延迟高，半同步容易失败
生产环境不能只靠半同步
半同步只是单点防线。真实故障中，它扛不住“主库宕机 + 所有从库都有执行延迟”的组合场景。必须补上三道硬性约束：
- 部署至少两个从库，其中一个设为
super_read_only = ON+skip_slave_start = 1，只收日志不执行，专用于切主前校验和接管 -
expire_logs_days ≥ 7，并禁用自动 purge，改用脚本先查SHOW BINARY LOGS和从库Relay_Master_Log_File，再手动PURGE BINARY LOGS TO - 所有从库也必须配置
sync_binlog = 1和innodb_flush_log_at_trx_commit = 1，否则切过去立刻变成新的单点风险源
最容易被忽略的是：切换动作本身不丢数据，丢的是“你以为它已执行”的那部分——而这个判断，只能靠 Exec_Master_Log_Pos 和 SQL 线程状态交叉验证，不是靠变量开关或日志里一句 “semi-sync enabled”。
