rpo=0指故障时数据零丢失，要求主备实时强同步；rto指恢复时间目标，即业务中断后恢复正常服务的最长容忍时长，金融核心系统通常要求rto
RPO=0 和 RTO
为什么 mysqldump + restore 无法满足异地RPO/RTO要求
它本质是逻辑备份，导出为单线程 INSERT 语句，导入时无法并发写入，且不包含 binlog 位点信息。一旦源库在导入中途故障，目标库状态不可知，RPO 可能高达数小时，RTO 则取决于导入剩余时间（TB级数据常超数小时）。
- 不支持断点续传，失败就得重来
- 无法校验迁移过程中新写入的数据是否已同步
- 目标库启动后需手动比对
SHOW MASTER STATUS与源库位点，操作不可自动化 - 即使加
--single-transaction，也仅保证导出一致性，不解决迁移窗口期数据丢失问题
必须用基于 binlog 的物理/半物理同步方案
异地容灾迁移要压低 RPO，核心是让目标实例持续消费源库的 binlog，而非“一次性搬运”。推荐路径：源库开启 GTID → 部署 MySQL Group Replication 或 Canal + Kafka + 自研消费者 → 目标实例以 ROW 格式回放。
-
GTID是跨云/跨机房同步的前提，避免传统file + position在网络抖动时错位 - 使用
ROW格式 binlog，确保 DML 变更可精确重放；STATEMENT格式在函数、临时表等场景下必然不一致 - 若走开源工具链，
Canal拉取后经Kafka缓冲，可抗短时网络中断，降低 RPO 波动 - 物理拷贝（如
xtrabackup）仅用于初始快照，之后必须立即接上 binlog 流，否则 RPO 从快照完成时刻开始累积
切换动作本身才是 RTO 的最大变量
RTO 不由同步速度决定，而由“确认可切”+“执行切换”+“验证可用”三段耗时叠加而成。很多团队卡在第一段：不敢切，因为没做过真实演练。
- 切换前必须验证
Seconds_Behind_Master = 0且Retrieved_Gtid_Set == Executed_Gtid_Set - DNS 或 VIP 切换不能依赖人工，需集成到运维平台，调用接口平均耗时
- 应用层必须配置
autoReconnect=true与合理connectTimeout，否则连接池会卡住数秒甚至分钟 - 首次切换建议先切只读流量，10分钟后无报错再切写入——这步省略，90% 的“切换失败”其实源于应用未适配新库延迟特性
两地三中心架构下，同城同步与异地异步的边界必须清晰
异地容灾迁移不是把所有复制都拉到几百公里外。标准做法是：同城灾备中心用 semi-sync 强同步保 RPO=0；异地灾备中心用 async + GTID + 延迟监控，接受分钟级 RPO，但确保 RTO 可控。
- 不要在异地链路上启用
semi-sync，网络抖动会导致主库事务阻塞，直接拖垮生产 RTO - 异地复制线程需单独配置
slave_net_timeout和master_retry_count，避免因超时退出后无人告警 - 用
pt-heartbeat而非Seconds_Behind_Master监控真实延迟，后者在空闲时恒为 0，有欺骗性 - 异地实例的
read_only=ON必须固化进启动参数，防止误操作污染数据，导致后续切换失效
真正难的不是技术选型，而是把“同步不丢数据”和“切换不炸服务”拆解成可测量、可触发、可回滚的具体步骤。每一步都要有对应日志埋点和阈值告警，否则 RPO/RTO 就只是文档里的数字。
