数据库无缝迁移：使用GCP数据库迁移服务实现MySQL平滑上云

2026-05-30 阅读 15
cloud


在互联网公司的架构演进中，最让人惊心动魄、如履薄冰的任务，绝对非“数据库迁移”莫属。

传统的数据库迁移就像是在高速公路上给狂飙的车换轮胎。为了保证数据一致性，老旧的做法通常是选择在凌晨三点挂起停机公告，切断所有前端流量，然后用 mysqldump 导出一个几十 GB 的大 SQL 文件，再慢吞吞地往云端传输、导入。结果往往是因为网络抖动中断、或者导入速度太慢，导致天亮了还没导完，最后只能在全员高压下被迫回滚，不仅让研发团队掉光了头发，还严重影响了公司的核心业务。

在 Google Cloud（GCP，谷歌云）的现代化生态里，有一个专为打破这个僵局而生的降维打击神器，叫做 Database Migration Service（数据库迁移服务，简称 DMS）。

它的核心逻辑非常纯粹：全托管、零停机、无缝实时同步。通过结合 MySQL 原生的 Binlog 复制技术，DMS 能够在线上业务照常开门接客的同时，在后台把老数据库的数据像流水一样源源不断地搬上云端。等两边数据完全对齐后，你只需要挑一个风平浪静的下午，花几秒钟把前端的连接字符串轻轻一改，就能完成大厂级别的“平滑上云”。

今天我们不扯复杂的密码学公式，拒绝任何废话。直接从硬核实战切入，手把手带你完成从本地自建 MySQL 到谷歌云 Cloud SQL for MySQL 的无缝迁移演练。

第一阶段：深度拆解，DMS 实时迁移的“两阶段物理世界模型”

在去控制台点鼠标之前，你必须在脑子里建立起 DMS 底层的物理运行模型，否则你绝对会被复杂的网络和权限配置给绕晕。

DMS 的全量+增量实时迁移，本质上是在谷歌内网底层搭建了一条高可用的数据传输管道，整个生命周期分为两个核心阶段：

  1. 第一阶段：存量大盘初始化（Full Dump）：当你启动迁移任务时，DMS 会在不影响你源库正常读写的前提下，闪电般地把源库当前存量的所有表结构、数据打包克隆一份，快速投递到云端的 Cloud SQL 目标库里。
  2. 第二阶段：增量流水追赶（CDC/Binlog 复制）：存量搬完的瞬间，DMS 会无缝切换到持续数据捕获（CDC）模式。它会化身为一个标准的 MySQL Slave（从库），死死盯着源库的 Binlog（二进制日志）。只要线上用户下了一个新订单、改了一个密码，DMS 就会在毫秒级把这条增量修改“抓”过来，在云端目标库里重放一遍。
核心架构结论：在这两个阶段里，你的老数据库全程保持对外营业，不需要停机哪怕一秒钟。云端新库就像是老库的影子，亦步亦趋，直到两边的数据时差（Replication Lag）归零。

第二阶段：实战前夜——在自建源数据库拉起“通行证”

为了让 DMS 能合法地进来搬砖，我们必须先回老家（本地自建的 MySQL 源库）做一些底层配置。

1. 开启 Binlog 日志（注入实时复制灵魂）

打开你源库的 my.cnf 或 my.ini 配置文件，确保以下行没有被注释，并且参数正确：

Ini, TOML


[mysqld]
log-bin=mysql-bin
binlog_format=ROW       # 必须是 ROW 格式，DMS 靠这个精准识别每一行数据的变动
server-id=100001        # 给源库指定一个唯一的集群身份 ID
expire_logs_days=7      # Binlog 至少保留 7 天，防止 DMS 还没来得及读就被系统自动删了

改完后，记得重启一下你的自建 MySQL 让配置生效。

2. 创建 DMS 专属“接头人”账号

连入源库，敲入以下大厂规范的 SQL 命令，为 GCP DMS 创建一个拥有专属复制权限的安全账号：

SQL


-- 创建一个叫 gcp_dms 的账号，允许它从任意地方（或指定 GCP 内网段）过来连
CREATE USER 'gcp_dms'@'%' IDENTIFIED BY 'YourHardPassword123!';

-- 授予基础的数据读取与集群复制权限（大厂最小权限原则）
GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'gcp_dms'@'%';

-- 刷新权限，让暗号瞬间生效
FLUSH PRIVILEGES;

第三阶段：实战演练——手把手配置 DMS 迁移流水线

环境准备就绪，我们登录 GCP 控制台，搜索并进入 Database Migration（数据库迁移） 页面。

步骤 1：创建迁移作业（Migration Job）

点击顶部的 “创建迁移作业”：

  • 作业名称：mysql-to-cloudsql-prod。
  • 源数据库引擎：选择 MySQL。
  • 目标数据库引擎：选择 Cloud SQL for MySQL。
  • 迁移类型：毫不犹豫选择 “持续（Continuous）”。注：只有选 Continuous 才是带增量同步的无缝平滑迁移；如果选 One-time（一次性），数据搬完就戛然而止，无法做到零停机切换。

步骤 2：定义源连接配置文件（Source Connection Profile）

在这里，我们要把第二阶段在老家配好的参数告诉谷歌：

  • 连接型配置文件名称：source-local-mysql。
  • 主机名/IP 和端口：填入你本地 MySQL 的公网 IP 或专线内网 IP，端口默认 3306。
  • 用户名与密码：精准填入刚才建好的 gcp_dms 及其密码。

步骤 3：定义云端目标库（Destination）

你要把数据搬到哪里去？DMS 在这里提供了一个极其无敌的功能——一键在后台帮你把全新的 Cloud SQL 目标库直接新建出来。

  • 输入你要新建的云端数据库实例 ID（如 cloudsql-mysql-prod）。
  • 选择 MySQL 的版本（建议与源库保持一致，如 8.0）。
  • 选择地域（如 asia-east1 台湾）。
  • 设置云端 root 账号的强密码，并选择机器规格（如 2核 4GB 内存，生产环境记得勾选“高可用性高防线”以启用跨可用区双活容灾）。

步骤 4：连通性攻坚战（Connectivity Method）—— 斩断黑客窥探

这是最容易踩坑卡壳的地方。谷歌云的 DMS 怎么穿过防火墙去连你本地的机器？DMS 提供了三种标准连通方式：

  • 高级推荐方案：反向 SSH 隧道（Reverse SSH Tunnel）：DMS 会在后台生成一个极轻量的中间 VM 虚拟机，并给你一串 SSH 命令。你只需要在本地服务器上运行这串命令，就能在本地和 GCP 内网之间拉起一条全加密、穿透防火墙的秘密单向隧道。你根本不需要在公司防火墙上给全球大开 3306 端口，安全系数直接挂满。
  • 备选方案：IP 允许列表：把 GCP DMS 提示你的那组官方公网 IP 地址，死死锁进你本地机房最外层的硬件防火墙白名单里。

连通性测试通过后，点击最底部的 “创建并启动作业（Create & Start Job）”。

第四阶段：见证奇迹的时刻——线上实时追赶与终极断流一切换

点击启动后，DMS 巨大的弹性分布式算力会被瞬间唤醒。回到迁移作业列表，你会盯着状态栏目睹它神奇的生命周期演变：

  1. 状态从 Creating 变成 Starting，再进入 Full dump in progress（代表它正在拼命搬运你过去几年沉淀的存量老数据）。
  2. 存量搬完后，状态会变成绿色的 CDC in progress（持续复制中）。

此时，去控制台看一眼 “复制延迟（Replication Lag）” 指标。刚开始由于存量搬运期间产生的新变动，延迟可能会有几分钟；但很快，随着谷歌强大的内网带宽火力全开，Replication Lag 会彻底归零（0 seconds）。

这意味着，此时此刻，你本地老库里的每一条数据，和谷歌云端 Cloud SQL 新库里的数据，已经达到了绝对的、像素级的完全实时同步。

大厂级标准的“黄金切流”操作五步法：

当延迟稳定在 0 秒后，我们就可以挑一个业务低谷期（比如下午 4 点用户访问最少的时候），进行最后的断流一切换。整个过程只需 10 秒钟：

  1. 前端挂起临时只读：在你的 Web 应用后台，或者在 MySQL 源库里执行 SET GLOBAL read_only = 1;，将老库强行变成“只读状态”。这个动作用来绝对确保在切换的这几秒钟内，不会有任何一笔新订单能偷偷写进老库、从而造成两边数据脱节。
  2. 静待最后查缺补漏：盯着 DMS 控制台，等待 5 秒钟，让最后一丁点正在传输的 Binlog 尾巴彻底在云端重放完毕，确保两边数据一期不差。
  3. 点击“升级（Promote）”大按钮：在 GCP DMS 控制台，果断点击顶部的 “升级（Promote）”。底层内幕：这个动作会瞬间切断云端新库和老库的奴隶复制关系。Cloud SQL 目标库会在一瞬间脱离从库身份，满血进化为一个完全独立、可读可写的顶级主库（Master）。
  4. 更换连接字符串：将你后端所有 Web 应用、微服务配置里的数据库连接 IP，从原本的老自建库 IP，一键修改指向全新的 Cloud SQL 公网/内网 IP。
  5. 重启应用，全盘复活：前端 App 重新连入云端新库，解除只读。新订单开始在谷歌云端以极高的性能疯狂落盘。

完美收工！整场战役下来，用户端只在第 1 步和第 4 步之间体验到了极其轻微的、短暂的“无法下单/报错”提示，网站整体从未挂过小黑屋公告，数据零丢失，上云大获全胜。

第五阶段：跨国数据库架构下的避坑血泪史

这套全托管迁移方案用起来优雅至极。但要在真正的企业级高并发生产环境里活下来，作为首席数据架构师，你必须防范以下两个由于底层技术细节差异衍生出来的隐形大坑：

1. 致命的“时区与字符集（Collation）灵异错乱”

很多团队迁移完发现，线上运行了半年的老代码，在连上云端 Cloud SQL 之后，所有的中国时间、本地时间全部莫名其妙地少了 8 个小时。或者某些包含生僻字、Emoji 表情的用户评论直接变成了乱码或报错。

  • 原因拆解：本地自建的 MySQL 默认时区通常会跟着宿主机走（比如设为了系统时区 CST），而 GCP Cloud SQL 默认为了全球合规，其底层主时区强制锁死为国际标准时间 UTC，字符集默认也可能与你的老库有细微差别。
  • 大厂标准避坑操作：在点击 DMS 启动迁移之前，去 Cloud SQL 的“配置更改”里，找到 数据库标志（Database Flags），显式地添加 default_time_zone = '+08:00'（或者契合你业务的主时区），并将字符集强行对齐为 utf8mb4。在源头卡死底层参数一致，是防止线上代码报错的第一铁律。

2. DMS 迁移完后的“扣费沙漏闲置陷阱”

很多新手在完美升级（Promote）了数据库、业务跑上云端后，就高高兴兴地去下班吃火锅了。结果月底翻看账单，发现产生了一笔莫名其妙、且价格不菲的 DMS 资源占用费。

  • 硬核止损建议：当你点击了“Promote”之后，DMS 这个迁移作业其实并没有被彻底物理销毁，它依然在云端后台占领着临时的计算资源和网络网络接口，扣费沙漏仍在疯狂运转。
  • 正确姿势：确认云端新库平稳运行 24 小时、确认不需要回滚后，必须立刻回到 DMS 控制台，选中那个已经完成的迁移作业，无脑点击“删除（Delete）”。别担心，删除作业绝不会对你已经进化成功的 Cloud SQL 数据库产生任何一丝一毫的影响，只有这样，扣费才算彻底停止。

总结

利用 GCP Database Migration Service 进行数据库无缝迁移，核心的工业级精髓就在于十六个字：配置落锁，隧道打通，Binlog追赶，升级切流。

你彻底告别了过去凌晨三点肉身盯防、提心吊胆的作坊式手工导出搬运。把所有的网络通信、大盘数据打包、实时状态同步交由谷歌顶级的全托管安全大脑去克隆。把核心的数据库资产平稳、丝滑地焊死在云端的高防地基之上，这才是现代云原生时代最优雅、最地道的架构师通关姿势。


cloud
← 返回新闻中心