半同步复制能显著降低rpo，但需主从复制正常、插件正确安装、wait_point设为after_sync、超时调至1秒，并持续监控rpl_semi_sync_master_status与clients，否则可能悄无声息降级为异步。
能显著降低RPO（Recovery Point Objective），但前提是配置正确且网络稳定；否则它可能悄悄降级为异步复制，你却毫无察觉。
确认主从基础复制已就绪再动半同步
半同步不是独立功能，它建立在标准异步主从复制之上。如果 SHOW SLAVE STATUS\G 中 Slave_IO_Running 或 Slave_SQL_Running 不是 Yes，或者 Seconds_Behind_Master 持续增长，强行启用半同步只会让主库事务卡住或频繁超时降级。
- 必须先确保主库开启了
log-bin，且从库能正常拉取并重放 binlog -
server-id在主从间必须唯一，不能重复 - 从库连接主库的账号需有
REPLICATION SLAVE权限，且网络端口（默认 3306）连通 - 建议用
mysqlbinlog --base64-output=decode-rows -v对比主从 binlog/relay log 内容，验证日志内容一致
插件安装与参数启用必须分主从执行
主库和从库加载的是不同插件，且启用开关也不同，混用会导致 Rpl_semi_sync_master_status 始终为 OFF。
- 主库执行：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';，然后设rpl_semi_sync_master_enabled = 1 - 从库执行：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';，然后设rpl_semi_sync_slave_enabled = 1 - 两个插件名不能写反，
semisync_slave.so在主库加载会报错或静默失败 - 动态设置后，从库必须重启 I/O 线程：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;，否则状态不更新
关键参数 rpl_semi_sync_master_wait_point 决定RPO是否真正“无损”
MySQL 5.7 默认是 AFTER_SYNC，这是实现低 RPO 的核心——它保证事务在 InnoDB 提交前，binlog 已落盘到至少一个从库的 relay log。若误设为 AFTER_COMMIT（5.6 默认），主库崩溃时可能丢失已提交但未同步的事务。
- 检查当前值：
SELECT @@rpl_semi_sync_master_wait_point;，应为AFTER_SYNC - 动态修改：
SET GLOBAL rpl_semi_sync_master_wait_point = 'AFTER_SYNC'; - 该参数必须在主库设置，从库不识别此变量
- 超时时间
rpl_semi_sync_master_timeout建议设为 1000（1秒）而非默认 10000：过长会导致主库阻塞明显，过短则易频繁降级
必须持续监控降级信号，否则RPO保障形同虚设
半同步不是“一配永逸”，它会在超时或从库失联时自动切回异步复制，此时 RPO 可能瞬间退化为无限大，而你从日志或状态里未必能立刻发现。
- 每分钟检查：
SHOW STATUS LIKE 'Rpl_semi_sync_master_status';和Rpl_semi_sync_master_clients——前者为ON且后者 ≥ 1 才算有效 - 注意
Rpl_semi_sync_master_no_times：该值持续增长说明频繁降级，需查网络延迟或从库 I/O 压力 - 不要只看
SHOW VARIABLES里的启用开关，它只反映配置，不反映实时运行状态 - 生产环境务必把
Rpl_semi_sync_master_status加入监控告警项，状态变OFF立即通知
最容易被忽略的一点：半同步只保障 binlog 到 relay log 的落盘，不保障 relay log 被 SQL 线程重放。如果从库 SQL 线程卡住（比如大事务、锁冲突），虽然半同步状态仍为 ON，但数据实际并未应用，RPO 依然不可控——得靠 Seconds_Behind_Master 和 Slave_SQL_Running_State 一起盯。
