RTO真实值需通过模拟主库宕机并实测切换总耗时获得，RPO上限由历史最大复制延迟、半同步配置、刷盘策略等共同决定；pt-heartbeat比Seconds_Behind_Master更准，但不解决RPO。
怎么看当前主从复制的RTO实际值
RTO（恢复时间目标）不是配置出来的，是故障发生后你真正花多少时间把从库切为主库并恢复服务——这取决于人工响应速度、切换脚本可靠性、应用重连逻辑，以及最关键的：Seconds_Behind_Master是否稳定在低位。
实操建议：
- 用
SHOW SLAVE STATUS\G持续观察Seconds_Behind_Master，但注意它可能为 0 却仍在追日志（比如 IO 线程停了但 SQL 线程刚追完）；更稳妥的是比对主库SHOW MASTER STATUS的File/Position和从库Relay_Master_Log_File/Exec_Master_Log_Pos - 模拟一次主库宕机：杀掉主库 mysqld 进程，立刻记录时间，然后执行切换（如修改 VIP、更新 DNS 或改应用配置），直到应用能正常写入新主库为止——这个总耗时才是真实 RTO
- 如果用了 MHA、Orchestrator 或自研切换工具，必须定期跑故障演练，否则 RTO 会远高于预期，尤其注意 DNS 缓存、连接池未清空、事务未提交导致的数据不一致残留
怎么算出当前架构的 RPO 上限
RPO（恢复点目标）由主从之间最大可能丢失的数据量决定，本质是“主库挂了，从库最多丢多少秒的 binlog”。它不等于 Seconds_Behind_Master 的瞬时值，而是历史峰值 + 网络抖动/从库负载突增等异常场景下的最差延迟。
实操建议：
- 开启
log_slave_updates并启用半同步（rpl_semi_sync_master_enabled=ON），可将 RPO 压到 1 个事务内（前提是至少一个从库 ACK）；但注意 MySQL 5.7 半同步有rpl_semi_sync_master_timeout默认 10 秒，超时后自动退化为异步，RPO 就不可控了 - 检查主库
sync_binlog设置：设为 1 才能保证 crash 后 binlog 不丢；设为 0 或 N>1 时，主库宕机可能丢失最后 N 个事务，这部分也计入 RPO - 从库若用
innodb_flush_log_at_trx_commit=2或sync_binlog=0，虽提升性能，但会放大 RPO——因为即使主库没丢，从库自己可能已丢日志
哪些配置会让 RPO/RTO 在故障时突然恶化
很多参数平时看着正常，一出问题就暴露短板。比如网络分区时，从库连不上主库，IO 线程断开，但 SQL 线程还在跑旧 relay log，Seconds_Behind_Master 反而显示 0，让人误判“一切正常”。
常见恶化点：
-
slave_net_timeout太大（默认 60 秒）：网络闪断后，从库要等一分钟才重连，期间完全停止同步，RPO 累积飙升 -
relay_log_recovery=OFF（MySQL 5.6 默认）：从库 crash 后重启，可能重复执行部分 relay log，造成主从数据错乱，切换后无法提供正确服务，直接拉长 RTO - 主库
binlog_format=STATEMENT：某些函数（如NOW()、UUID()）在从库重放结果不同，导致数据不一致，切换后需人工修复，RTO 不可控 - 没开
read_only=ON在从库：运维误操作直接写从库，后续切换时主从冲突，RTO 变成数据抢救时间
用 pt-heartbeat 能不能代替 Seconds_Behind_Master
可以，而且更准。因为 Seconds_Behind_Master 是基于 SQL 线程执行位点推算的，而 pt-heartbeat 是主库定时写心跳记录、从库实时读取时间差，绕过了复制机制本身的误差源。
使用要点：
- 必须在主库上持续运行
pt-heartbeat --update --daemonize，写入专用表（如percona.heartbeat）；从库查该表的时间差才是真实延迟 - 别只看单个从库：用
pt-heartbeat --check批量查所有从库，挑延迟最小的那个作为切换候选，否则 RTO 会被最慢节点拖累 - 注意权限：该工具需要
SELECT、INSERT、UPDATE权限，且表引擎必须是 InnoDB（避免 MyISAM 表级锁干扰） - 它不解决 RPO，只让 RTO 预估更稳；RPO 还得靠半同步 + 正确的刷盘策略来保
