故障转移后数据同步需主动干预、精准识别、分阶段补全：先确认新主库位点与原主库故障前位点差值，定位缺失区间；用wal/redo日志工具解析并重放未同步事务；部署双向同步链路防回退；通过主键+时间戳抽样、pt-table-checksum等工具验证逻辑一致性。
故障转移后，数据同步追赶不是“等它追上”，而是要主动干预、精准识别、分阶段补全。核心在于区分哪些数据已落库、哪些卡在传输链路、哪些根本没发出，再按优先级执行修复。
先确认新主库的起点状态
切换完成后，不能默认“从备库升主就天然一致”。需立即检查：
- 新主库的最新事务位点（如 PostgreSQL 的 LSN、MySQL 的 GTID_SET）
- 原主库故障前最后写入的位点（若仍可访问，直接查；不可访问则依赖日志归档或监控快照）
- 对比两者差值，明确“缺失区间”——这才是追赶的真正范围
用 WAL/Redo 日志做精准补漏
异步复制场景下，部分事务常滞留在原主库 WAL 中未发送。此时不能只靠常规复制重连，而应人工介入解析：
- 使用 walminer（PG）、mysqlbinlog（MySQL）或 Oracle LogMiner 工具，提取原主库故障时刻之后、尚未同步到新主的 WAL/Redo 片段
- walminer 4.0 的 fosync 功能可自动定位并生成可重放的 SQL 或逻辑变更事件，支持直接 apply 到新主库
- 注意：操作前需停写或灰度引流，避免 apply 过程中产生新冲突
双向同步链路兜底防回退失联
单向主从在故障后容易陷入“断连即失联”困境。更稳妥的做法是提前部署双向同步：
- 割接前以旧库为主、新库为备，实时同步增量
- 切换后立即反向建立新→旧同步，让旧库持续接收新主的写入
- 这样即使需回切，旧库已是最新状态，RTO 可压缩至分钟级
验证一致性不能只看行数
追赶完成后，简单比对表行数或 checksum 容易漏掉逻辑不一致（如更新覆盖、删除未同步）。建议：
- 抽样校验关键业务表的主键+更新时间戳组合
- 运行差异检测工具（如 pt-table-checksum + pt-table-sync）扫描全量数据逻辑差异
- 对金融类系统，额外核对全局事务 ID（GTID 或 XID）序列连续性
