GCP 数据库怎么平滑迁移？利用 Database Migration Service (DMS) 实现不停机迁移
在云计算的领域里，有一件事能让所有架构师和运维（SRE）通宵加班、提心吊胆，那就是数据库迁移。
很多人一听到“迁库”，脑海里浮现的画面就是：挑一个大年三十或者凌晨三点的业务低峰期，挂起首页公告“系统维护中”，然后急急忙忙地导出 SQL、传输文件、导入新库、修改配置……整个过程如同高空走钢丝，一旦中间哪个环节卡住或者数据对不上，业务停服时间就会无限拉长。
但实际上，现在的云厂商早就不流行这种“杀敌一千，自损八百”的硬核搬家方式了。今天我们就来聊聊谷歌云（GCP）提供的一款神器——Database Migration Service (DMS)。
作为在生产环境滚过满身泥的过来人，我今天用最通俗易懂的语言，不扯官方文档那些让人昏昏欲睡的术语，手把手教你如何利用 DMS 实现“零停机（Minimal Downtime）”的平滑搬家。
一、 核心概念：什么是 DMS 的“零停机搬家”？
在动手之前，我们先花一分钟搞明白它的底层逻辑。DMS 之所以能做到“零停机”，核心在于它不是一次性把数据扔过去，而是分成了两个阶段：谷歌云账号购买
- 全量初始化（存量数据复制）：DMS 会先把源数据库里现有的所有历史数据，完整地复制到 GCP 的目标库（比如 Cloud SQL）中。在这个过程中，你的线上业务照常运行，正常的读写完全不受影响。
- 增量同步（实时追数据）：当历史数据传完后，DMS 会通过读取源库的日志（比如 MySQL 的 Binlog 或 PostgreSQL 的 WAL），把全量搬家期间新产生的业务数据，源源不断地“同步”到新库中。这时候，新旧两个库的数据几乎是完全实时同步的。
由于新旧库数据保持一致，你可以在大白天、业务最清闲的时候，优哉游哉地把应用程序的数据库连接字符串（Connection String）改成新库的地址。业务中断时间仅仅是重启应用、切换配置的那几十秒，甚至几秒钟。
二、 搬家前的“三道安检”（准备工作）
用 DMS 搬家就像坐飞机，安检做好了，航行就成功了一半。以下三点直接决定了迁移会不会失败：
1. 开启源库的日志（最关键的一步）
DMS 必须要能读取你源库的实时日志，才能做增量同步。
- 如果源库是 MySQL：你必须确保开启了 binlog，并且 binlog_format 必须设置为 ROW，binlog_row_image 设置为 FULL。
- 如果源库是 PostgreSQL：你需要把 wal_level 设置为 logical，并配置好复制槽（Replication Slots）。
2. 想好网络怎么通（连通性方案）
源库和 GCP 之间必须能安全地说话。DMS 提供了几种连接方式，按照安全和推荐程度排序：
- VPC peering（VPC 对等连接）：如果你的源库已经在 GCP 的另一个 VPC 或者是通过专线（Interconnect）连通的机房，这是首选，速度快且安全。
- Reverse SSH Tunnel（反向 SSH 隧道）：最常用的平民方案。在源库的网络里开一台小虚拟机作为跳板机，通过加密隧道让 GCP 连进来。
- IP 允许列表（Public IP）：最简单但也最不推荐。直接把源库的公网 IP 暴露给 DMS 的 IP 范围。如果只是测试可以这么干，生产环境慎用。
3. 创建迁移账号
谷歌云账号购买不要直接用 root 或 admin 这种至高无上的账号去跑迁移。在源库专门创建一个临时的 dms_user，只给它赋予必要的读取、复制权限（例如 MySQL 的 REPLICATION CLIENT, REPLICATION SLAVE, SELECT 等）。搬家结束后，直接把这个账号删掉，安全又优雅。
三、 实战：DMS 配置四步走
准备工作做完，我们直接进入 GCP 控制台，搜索 Database Migration。
第一步：创建“迁移作业（Migration Job）”
点击创建后，你需要填入作业的基本信息：
- 源数据库类型：比如自建的 MySQL、AWS RDS 或者是其他云的数据库。
- 目标数据库类型：通常是 GCP 托管的 Cloud SQL 或 AlloyDB。
- 迁移类型：毫不犹豫选择 “持续同步（Continuous）”。只有选这个才是零停机搬家；如果选“一次性（One-time）”，那数据传完就结束了，不包含后续的增量同步。
第二步：配置源连接（Connection Profile）
这里就是把我们刚才准备的“安检信息”填进去：
- 输入源库的 IP 地址、端口、刚才创建的 dms_user 账号和密码。
- 选择你定好的网络连通方式（比如配置好 Reverse SSH 隧道）。
- 点击“测试连接”，确保进度条变成绿色。如果报错，通常是防火墙或者安全组没放行，回去检查网络。
第三步：配置目标库（Cloud SQL）
如果目标 Cloud SQL 还没创建，DMS 允许你直接在界面里“一键新建”。
- 你可以选择与源库一样的配置（CPU、内存、存储空间）。
- 强烈建议：在这里顺便把目标库的高可用（HA）和自动备份勾选上，一步到位。
第四步：开始校验并运行（Start Job）
点击运行前，DMS 会有一个非常强大的“预检查（Pre-flight check）”功能。它会自动帮你检查：源库的日志格式对不对？权限够不够？版本兼不兼容？
如果有红色报错，根据提示去源库改配置；如果全是绿色勾，直接点击 “开始（Start）”。
四、 割接（Cutover）：如何完美打响“最后一枪”
当作业运行起来后，你会看到状态变成 Full dump in progress（全量导出中），接着变成 CDC in progress（增量同步中）。
当状态进入 CDC in progress 且 “同步延迟（Lag）”趋近于 0 的时候，意味着新库和旧库的数据已经完全同步了。这时候，我们就可以准备真正的“割接”了。
这里是决定零停机成败的精髓，请严格按照以下步骤操作：
1. 业务切向“只读”
为了防止在切换连接的几秒钟内有新的数据写错地方，先在应用层或者源数据库上，将业务设置为“只读模式（Read-Only）”。
2. 等待 DMS 最后一波数据追平
观察 DMS 界面，确保延迟（Lag）彻底变成 0。这代表源库在只读前产生的最后几条数据，已经稳稳地躺在 GCP 的新库里了。
3. 在 DMS 上点击“完成（Promote）”
在 GCP 控制台点击 “Promote” 按钮。这个动作会做两件事：
- 断开新库与旧库的同步关系。谷歌云账号购买
- 把目标 Cloud SQL 从“只读的接收方”提升为“完全可独立读写的生产主库”。
4. 修改应用配置，全量上线
把你们应用程序的数据库连接配置，改成新 Cloud SQL 的 IP 地址，取消应用的只读模式，重新启动服务。
检查业务，看看前台下单、后台登录是否正常。如果一切顺利，恭喜你，这场惊心动魄的数据库大搬家，在用户完全没有感知的情况下，圆满完成了！
五、 新手避坑与经验谈
虽然 DMS 很好用，但作为过来人，有几个隐形大坑必须提醒你：
- 大表缺少主键（Primary Key）：如果你的源库里有一些非常大的表，里面居然没有设主键，DMS 在做增量同步（CDC）时性能会极差，甚至可能导致同步卡死。迁移前，务必让开发同学把没有主键的表补上主键。
- 网络带宽不要省：全量搬家阶段非常消耗网络带宽。如果你的源库在本地机房，专线或者公网带宽太小，不仅搬家会搬几天几夜，还可能把你们机房的正常业务带宽给挤爆。记得在业务低峰期启动全量搬家，或者在 DMS 里设置流量限制。
- 注意时区（Timezone）问题：Cloud SQL 默认是 UTC 时区。如果你的源库是用的是 Asia/Shanghai（东八区），迁移后应用查出来的时间可能会莫名其妙少 8 个小时。记得在创建目标库时，把时区参数（default_timezone）调整得和源库一模一样。
📝 总结
GCP 的 Database Migration Service（DMS）本质上是一个免费的无服务器（Serverless）迁移工具（你只需要支付迁移过程中目标库的硬件和网络费用，DMS 本身不收软件费）。
它把曾经高门槛、高风险的“手动人肉迁库”，变成了标准化、可视化的点点鼠标。
最后一句话总结：
不要再用停机维护的旧思维去折腾生产环境了。利用 DMS 做持续增量同步，把主动权抓在自己手里，白天喝着咖啡就能把库迁完，这才是现代云原生运维该有的优雅姿势！