校验是贯穿全程的动态保障机制，而非一次性动作：分阶段校验嵌入四阶段迁移流程，增量期持续比对位点与热点主键，灰度期自动双查比对，切写前终验关键字段；存储层延伸至物理校验与备份恢复演练；全链路依赖自动化工具闭环，失败时异步修复、一键回切，确保业务零中断。
生产环境不停机实现数据库与存储的平滑迁移，校验不是“一次性动作”，而是贯穿全程的动态保障机制。核心逻辑是：不依赖停机窗口做最终比对，而是靠“分阶段校验 + 实时兜底 + 渐进确认”来建立可信度。
分阶段校验：每步都可验证、可回退
校验必须嵌入四阶段迁移流程中，而非等到最后才启动：
-
全量迁移后立即校验：只比对行数、主键分布、索引有效性（如 MySQL 的
CHECK TABLE），不扫全量数据；用抽样哈希（如按时间分区或 ID 取模）比对 0.1%~1% 的关键字段值，5 分钟内完成亿级表初筛。 - 增量同步期间持续校验：基于 binlog/redo log 位点，定期（例如每 5 分钟）比对源库与目标库的最新事务序列号、变更计数器，发现延迟立即告警；对高频更新的热点主键做实时双查（读源库+读目标库，比对结果一致性）。
- 灰度切读阶段校验：将部分用户流量路由到新库，同时保留源库读能力，应用层自动比对两次查询结果（如返回 JSON 字段 MD5），异常自动降级并记录差异样本，用于定位字段类型转换或时区处理问题。
- 切写前终验：在双写开启后，抽取最近 1 小时所有写入主键，反查源库和目标库完整记录，逐字段比对；重点检查大文本、时间戳、枚举值、空值处理等易出错字段。
存储层校验：不止看数据库，还要覆盖底层文件与元数据
当迁移涉及存储引擎变更（如从 InnoDB 切到 KingbaseES 或 ClickHouse），校验需延伸至物理层：
- 确认目标库已启用相同级别的数据校验机制（如 PostgreSQL 的
data_checksums=on，KingbaseES 的页级 CRC 校验）； - 对冷数据归档目录（如 OSS/S3/HDFS）执行对象级 SHA256 校验，确保导出文件未损坏；
- 比对源库与目标库存储统计信息：表实际占用空间、碎片率、WAL/Redo 日志体积增长趋势，异常突增可能意味着索引未重建或压缩未生效；
- 验证备份链路是否就绪：用目标库快照执行一次真实恢复演练，确认 RTO 符合 SLA（例如 5 分钟内可拉起可用实例）。
自动化工具链：把校验变成可调度、可审计、可沉淀的动作
人工校验无法支撑亿级数据高频迭代，必须依赖工具闭环：
- 使用 KDTS 或 Canal Admin 内置的校验模块，配置规则后自动生成每日一致性报告，包含差异表清单、误差率、高风险字段；
- 将校验脚本封装为 Prometheus Exporter，关键指标（如“主键缺失数”“字段值偏差率”）接入 Grafana，设置阈值告警；
- 所有校验操作留痕：记录执行时间、比对范围、样本策略、负责人、是否通过；失败项自动创建工单并关联原始 binlog 位点，便于快速复现；
- 校验结果直接驱动流程：只有灰度读校验误差率低于 0.001%，且连续 3 次通过，才允许进入下一阶段切流。
兜底设计：校验失败时系统仍可控
校验不是为了“卡住流程”，而是为了暴露问题并快速响应：
- 所有校验均采用“异步非阻塞”方式，不影响主业务链路；
- 发现差异时，优先启用“旁路修复”：如通过 CDC 工具重推指定主键范围的数据，而非全表重刷；
- 预留“一键回切”开关：当校验持续失败或误差扩大，可 30 秒内将读写全部切回源库，双写日志保留供事后分析；
- 对无法自动修复的语义差异（如 Oracle 的
NVL()在 PostgreSQL 中需转为COALESCE()），生成映射报告交由开发确认，不阻断迁移主流程。
