别把数据迁移当复制粘贴：一线人踩坑总结的云上 / 跨云迁移实战指南

写在前面一句掏心窝子的话：
数据迁移不是技术活，是心理活。
真正让人睡不着觉的，从来不是 SQL 写得漂不漂亮，而是——
👉 “万一切换那一刻炸了，能不能回得来？”

我这几年帮企业做过不少 云上 / 跨云数据迁移，从 IDC → 公有云、阿里云 → 华为云、腾讯云 → 私有云，甚至还有“领导拍脑袋型”的 今晚迁，明早上线。
踩过的坑，说实话，比写过的代码还多。

今天这篇文章，我不打算写成 PPT 教科书风，而是从方案、风险、回滚这三个真正要命的点，聊点 实战 + 血泪 + 方法论。

一、先泼一盆冷水：数据迁移，90%的人想简单了

很多人对数据迁移的第一反应是：

“不就是把数据从 A 拷到 B 吗？”

但在真实世界里，迁移意味着同时改变 至少 5 件事：

1. 存储介质变了（本地盘 → 对象存储 / 云盘）
2. 网络拓扑变了（同机房 → 跨地域 / 跨云）
3. 权限模型变了（本地账号 → IAM）
4. 性能假设变了（低延迟 → 高抖动）
5. 兜底能力变了（人肉 SSH → 工单 + SLA）

👉 所以我一直说一句大白话：

数据迁移，本质是一次“系统级重构”，只是你没改业务代码而已。

二、迁移方案别一上来就“全量一把梭”

1️⃣ 常见的三种迁移方案（说人话版）

✅ 方案一：全量迁移 + 停机切换（最简单，也最危险）

适合场景：

• 数据量不大
• 允许停机
• 系统复杂度低（比如内部系统）

流程一句话版：

停业务 → 全量导出 → 全量导入 → 改配置 → 起业务

问题也一句话：

一旦失败，业务等你。

✅ 方案二：全量 + 增量（现实世界的主流）

这是我最常用、也最推荐的方案。

核心思路：

• 先把“历史数据”慢慢搬完
• 再用增量同步兜住实时写入
• 最后在一个极短窗口完成切换

逻辑示意：

历史数据 ──► 新云
实时写入 ──► 双写 / CDC

✅ 方案三：双活 / 灰度迁移（最优雅，也最烧钱）

适合场景：

• 核心系统
• 金融 / 电商 / 中台
• 对稳定性极度敏感

一句话总结：

不是搬数据，是“慢慢换心脏”。

三、代码不是重点，但“校验代码”一定要有

迁移过程中，最容易被忽略、但最关键的，是数据校验。

我见过太多项目：

• 数据搬完了

• 业务也切了

• 半个月后用户说：

  “咦？我三年前那条记录怎么没了？”

一个最朴素但极其重要的校验思路

1️⃣ 行数校验（最低配）

def count_check(src_conn, dst_conn, table):
    src_cnt = src_conn.execute(f"select count(*) from {table}").fetchone()[0]
    dst_cnt = dst_conn.execute(f"select count(*) from {table}").fetchone()[0]
    return src_cnt == dst_cnt

我知道它很土，但它能第一时间救命。

2️⃣ 核心字段 checksum 校验（强烈推荐）

import hashlib

def checksum(rows):
    m = hashlib.md5()
    for row in rows:
        m.update(str(row).encode("utf-8"))
    return m.hexdigest()

行数一致 ≠ 数据一致
没有 checksum 的迁移，都是自我安慰。

四、风险不是“可能发生”，而是“一定会发生”

下面这几条，是我真实项目中 100% 中过的雷。

⚠️ 风险一：网络抖动把你拖进深渊

跨云迁移，网络一定不稳定。

解决经验：

• 所有迁移任务必须 可断点续传
• 每个批次必须 幂等
• 宁可慢，也别赌

⚠️ 风险二：时间窗口算错，切换变事故

很多人低估了这一步：

“最后同步一下，应该很快吧？”

现实往往是：

• 写入高峰没算进去
• 索引重建时间没算进去
• 云厂商限速没算进去

👉 我的经验法则：

你以为要 10 分钟的操作，至少预留 1 小时。

⚠️ 风险三：权限 & 字符集这种“阴招”

• MySQL utf8 → utf8mb4
• 大小写敏感
• 时区变化
• IAM 权限默认拒绝

这些问题不会第一时间炸，但一定会在凌晨两点炸。

五、回滚策略：真正的底气，不是勇气

我见过最危险的一句话是：

“没事，出问题再说。”

一个合格的迁移方案，必须提前回答这三个问题

1. 切换失败，能不能 5 分钟内回去？
2. 回滚是自动的，还是靠人？
3. 回滚期间数据会不会丢？

一个我常用的“土但稳”的回滚策略

核心原则：切换 ≠ 删除

• 旧系统 至少保留 1~2 个业务周期
• 新系统写失败，立即切回旧系统
• DNS / 网关 / 配置中心支持秒级回切

# 示例：通过配置中心控制读写指向
DATA_SOURCE=old_db   # or new_db

真正成熟的系统，切换只是一行配置。

六、说点不太“技术”的真心话

做了这么多年数据迁移，我最大的感受是：

• 技术方案能写得很漂亮
• 但真正决定成败的，是 保守、克制、敬畏

👉 迁移不是炫技的舞台，而是风险控制的艺术。

我现在做迁移项目，反而越来越“怂”：

• 能灰度就不全量
• 能慢慢跑就不熬夜
• 能回滚就不硬刚

因为我知道：

真正的高手，不是一次都不失败，而是失败也能体面收场。

七、最后一句送给正在做迁移的你

如果你现在正准备做云上 / 跨云数据迁移，我只送你一句话：

方案写给领导看，回滚写给自己活。