异地容灾核心目标是“可切换”而非“同步”，采用“异步复制 + 日志补位 + 定期校验”三层架构，确保 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 流水线与主库变更联动同步，避免切换后语法报错或结果偏差。
跨机房灾备不是 DBA 一个人的事，是数据库、中间件、应用、运维、SRE 共同定义 SLA、共建可观测性、共担切换责任的过程。
