数据库迁移实战：同构/异构、双写切换、数据校验与灰度回滚

① 全量迁移：把存量数据完整搬到目标库
② 增量迁移：把存量搬完之后产生的变更持续同步
③ 校验切换：确认两边一致后，才把读/写切到目标

任何只做 ①② 不做 ③ 的迁移，都是自欺欺人的"搬迁"，不是"迁移"。

# 朴素 dump：导出期间产生新写入，两端对不上
mysqldump -u root db orders > orders.sql
# 此时 orders 里又有新数据写入 → 无法证明两端一致

# 1) 全量：带 --single-transaction（InnoDB MVCC 快照）导出一致快照
mysqldump --single-transaction --set-gtid-purged=OFF -u root db > snapshot.sql

# 2) 记录起始位点
SHOW MASTER STATUS;
# File: mysql-bin.000003  Position: 2345

# 3) 导入目标库
mysql -h target -u root db < snapshot.sql

# 4) 从位点 2345 起，用 CDC 工具回放增量 binlog
#    （Canal / DTS 订阅 binlog，catchup 到接近实时）

双写阶段拓扑：
  应用 → 写源库 ✓  写目标库 ✓
            ↓         ↓
        (源可回滚) (目标验证)

校验通过 → 流量切到目标 → 观察期（如 1~4 周）
   → 全量校验仍一致 → 关闭源库写入 -> 迁移完成

-- 对两端逐行做 checksum 对比
SELECT COUNT(*) FROM orders;                      -- 行数一致
SELECT CRC32(GROUP_CONCAT(id)) FROM orders;       -- 抽样校验

推荐校验动作：
  1. 行数校验：两端 count 一致
  2. 抽样字段一致性：对主键/时间/状态等关键列做 CRC 对比
  3. 全量慢校验：业务低峰用 SELECT SUM/CRC 连表做全量对账
  4. 校验窗口：迁移期间持续对账，确保增量也没丢

灰度路径：
  ① 只读副本（目标库只作为读副本，10% 读流量）
  ② 大流量校验通过 → 切主读
  ③ 业务切写（通常是双写/物理切换）
  ④ 参数回滚窗口：低频接口保留读源库

关键：每个阶段都有独立可逆的旋钮，
      而不是一次大爆炸式切换。

# 预写回滚脚本，切换前所有人会签字
# 内容模板：
#   1) 把写流量重新指回源库
#   2) 停止对目标库的写入
#   3) 回放 binlog 至切换点，追平目标库的滞后
#   4) 校验回滚后一致

# 回滚成功标准：源库写正常、数据与切换点对账一致、无脏数据残留