异地容灾核心目标是“可切换”而非“同步”，采用“异步复制+日志补位+定期校验”三层架构，确保rto 15–30分钟内完成切换、故障可识别、决策稳、一致性可验证、应用低损回切，并需全链路协同保障元数据与应用层适配。
异地容灾的核心目标不是“同步”，而是“可切换”
跨机房数据库灾备，首要解决的不是数据零丢失（RPO=0），而是当主数据中心完全不可用时，能在合理时间内（如15–30分钟）将业务切到备用机房并持续提供服务。过度追求强同步反而会拖慢主库性能、增加网络抖动敏感度，甚至引发脑裂。真正关键的是：故障识别快、切换决策稳、数据一致性可验证、应用无感或低损回切。
推荐采用“异步复制 + 日志补位 + 定期校验”三层架构
这是当前多数中大型系统在成本、稳定性和RTO/RPO间取得平衡的主流方案：
- 主中心写入后异步推送binlog/redo日志到异地备库，不阻塞主库事务，保障高并发性能；
- 备中心部署轻量日志接收与重放服务，支持断点续传、延迟监控、流量限速（避免突发大事务压垮备库）；
- 每小时自动比对主备关键表的校验和（如CRC32或MD5聚合），异常时触发告警并标记不一致区间，供人工介入或自动补偿。
切换流程必须预演、可回滚、带灰度能力
真实故障下的切换不是执行一条命令，而是一套受控操作链：
- 先冻结主库写入（如通过中间件拦截或DB代理下线），确保最后一批日志被完整捕获；
- 等待备库追平日志（监控Seconds_Behind_Master或GTID Executed差值归零），再校验关键业务表行数与摘要；
- 通过DNS权重、服务注册中心或API网关，分批次将流量导至新主库（例如先切5%订单查询，再切全部读，最后切写）；
- 全程保留主库只读快照，一旦新主库出现逻辑错误（如误删、SQL注入扩散），可在5分钟内回切并恢复业务。
别忽略应用层适配和元数据一致性
数据库切走了，但应用未必能跟上：
- 连接池需支持动态刷新数据源地址（如Druid的DynamicDataSource、ShardingSphere的DistSQL）；
- 分布式ID生成器（如Snowflake）、本地缓存（如Caffeine）、定时任务调度（如XXL-JOB）等组件，必须跨机房统一配置或具备机房感知能力；
- 数据库账号权限、函数、存储过程、时区设置、字符集等元信息，需通过CI/CD流水线与主库变更联动同步，避免切换后语法报错或结果偏差。
