rpo=0在mysql中必须依赖after_sync半同步复制+sync_binlog=1、innodb_flush_logs_at_trx_commit=1等严格参数协同，因mysqldump/xtrabackup仅为时间点快照，无法覆盖备份间隔内事务，而after_sync确保客户端收到成功响应时binlog已刷盘至至少一个从库。
RPO=0 在 MySQL 中无法靠单一备份手段实现，必须依赖实时日志同步机制（如半同步复制）+ 严格参数配置 + 可靠硬件/网络，备份只是兜底手段。
为什么 mysqldump 或 xtrabackup 本身做不到 RPO=0
物理或逻辑备份都是某个时间点的快照，即使每分钟执行一次，两次备份之间产生的事务仍会丢失。RPO=0 要求“任意时刻宕机，已确认的事务不丢”，这只能靠 binlog 实时落盘到至少一个从库来保障，而不是靠备份文件生成时机。
-
mysqldump是逻辑快照，导出期间新写入的数据不会包含在备份中； -
xtrabackup做的是物理一致性快照，但仅保证备份时刻数据页一致，不捕获之后的任何变更； - 备份再快也有窗口：哪怕 10 秒一备，这 10 秒内提交的事务若未被 binlog 复制出去，就可能丢失；
- 备份文件本身不提供“事务可见性”与“日志持久化”的绑定关系——而这正是 RPO=0 的核心。
rpl_semi_sync_source_wait_point = 'AFTER_SYNC' 是硬性前提
这是 MySQL 官方半同步插件中唯一能逼近 RPO=0 的模式。它强制主库在 InnoDB commit 前等待至少一个从库将接收到的 binlog 写入并 fsync 到 relay log 文件。
- 必须显式设置：
SET GLOBAL rpl_semi_sync_source_wait_point = 'AFTER_SYNC'; - 不能只装插件就完事：需确认
plugin_load_add加载了semisync_source.so和semisync_replica.so； - 从库 IO 线程必须重启才能生效（旧连接不感知新 wait_point）；
- 若超时（
rpl_semi_sync_source_timeout），主库会自动降级为异步，此时 RPO > 0 —— 所以超时值要设得足够大（比如 10000ms），但也不能无限大，否则阻塞业务； - 该模式下客户端收到成功响应时，binlog 已确定刷盘到至少一个从库的磁盘，不是仅在内存或 OS Page Cache 中。
配套参数缺一不可，否则 AFTER_SYNC 形同虚设
就算设置了 AFTER_SYNC，如果底层日志没真正落盘，还是可能丢数据。关键参数必须协同生效：
-
sync_binlog = 1：每次事务提交都强制fsyncbinlog 文件，防止 OS 缓存延迟写盘； -
innodb_flush_logs_at_trx_commit = 1：确保 redo log 同步刷盘，这是 InnoDB 持久化的底线； - 从库必须启用
relay_log_recovery = ON，避免 relay log 损坏导致复制中断后无法继续； - 主从网络需稳定低延迟，高丢包或抖动会导致半同步频繁超时降级；
- 存储设备建议用支持断电保护（PLP）的企业级 SSD，避免掉电时 write cache 中的数据丢失。
备份的角色是兜底，不是主力
即使做到了 RPO≈0，仍需备份，但它不再承担“防丢”任务，而是应对人为误操作、逻辑错误、勒索软件等场景：
- 全量备份建议用
xtrabackup，每周一次，保留至少 4 周； - binlog 必须开启并保留 7 天以上，配合全备可实现任意时间点恢复（PITR）；
- 备份文件必须异地存放，且定期执行
xbstream解压 +mysql导入验证，光有文件不等于能恢复； - 不要把备份路径放在和数据库同一块物理盘上——主库崩溃时，备份盘也可能一同损坏。
真正容易被忽略的，是网络稳定性与存储可靠性这两层“看不见的依赖”。参数调得再准，只要网卡偶发丢包或 SSD 断电丢缓存，AFTER_SYNC 就会悄悄失效，而监控往往只报“半同步降级”，不会直接告警“RPO 已突破”。
