谷歌云数据库迁移实战：跨云不停机迁移MySQL完整指南

在云厂商众多的当前市场环境下，各种云在售价、性能、功能、售后等方面都存在较大差距，很难找到一朵在所有方面都最佳的云。因此，跨云迁移成了许多企业的选择-3。

但跨云迁移听上去简单，实际操作却相当复杂。大部分云厂商提供的配套迁移产品只进不出——只针对自建库上自身云提供了良好支持，但对于从自身云迁出的需求，往往无法满足-3。

一、跨云迁移的四重挑战

1.1 安全性问题

出于安全性考虑，云数据库通常是封闭的内网环境。在配套迁移产品无法提供迁出支持的前提下，想要迁移数据必须得开启公网访问地址。而这一举动无疑给不法分子提供了攻击数据库的绝佳良机——数据库可能被攻陷，重要数据遭到泄露，甚至直接被清空-3。

1.2 业务可用性

迁移必须在不影响业务的前提下进行，换句话说，迁移时不能停机。那需要考虑的事情就非常多了：存量和增量数据如何完整迁移？如何处理迁移时的性能波动？如何实现应用程序的平滑切换？-3

1.3 表结构与变更联动

当待迁移表数量巨大，且迁移过程中源库发生DDL操作的情况下，如何实现高效且稳定的数据库迁移无疑是一大挑战-3。

1.4 迁移失败止损

不同的云在功能与性能上表现迥异，迁移复杂度较高。当业务出现迁移失败的情况下，如何有效保障业务的可用性也是需要考虑的重点问题-3。

二、解决方案：NineData数据复制

NineData的数据复制功能专门针对上述痛点设计，提供了一套完整的跨云数据库迁移方案-3。

2.1 免开公网的安全连接

NineData集成各个云厂商的私网环境，迁移无需在云数据库端开启公网访问链接。对于比较不常见的云厂商，还提供了网关功能，同样可以免开公网直接访问到数据库，让迁移链路安全又高效-3。

2.2 业务不停机迁移

NineData提供结构迁移、全量数据迁移及基于redo log的CDC增量数据迁移能力。在数据库迁移过程中，源端可正常提供服务-3。

当NineData进入到增量数据迁移阶段且复制无延迟时，业务可以在目标端中进行只读验证，并借助NineData数据对比工具进行数据一致性验证。业务验证通过后，再进行业务停机切换。整个迁移过程业务停机时间非常短-3。

2.3 强劲的复制性能

NineData基于日志分析、智能分片、动态攒批、数据合并、特有数据格式等技术，有效保障全量数据复制、增量数据复制的性能。当前NineData全量复制性能高达200 GB/小时，增量数据复制性能高达2万记录/秒-3。

2.4 完善的迁移回滚方案

不同云数据库之间在功能、性能上相差较多，涉及大量的业务改造及性能调优，迁移割接的难度极高。为降低割接失败的风险，业务通常都需要做好割接失败的回滚预案-3。

NineData提供了CDC增量复制能力，支持从源端实时采集、解析日志并同步增量至目标端。当业务从源端切换到目标端之前，可以在NineData搭建一条从目标端实时回流增量数据至源端的复制任务。基于此复制任务，可以将业务割接完成后产生的新数据同步回流至源端，使源端保留完整的业务数据-3。

一旦出现因目标端的功能或性能导致的业务运行问题，可随时将业务回切回源端，有效规避业务迁移故障-3。

三、迁移实战：MySQL到GCP Cloud SQL

3.1 第一步：录入数据源

登录NineData控制台，单击“数据源管理”>“数据源”，然后在页面中单击“创建数据源”，选择需要的云厂商。根据页面提示，通过私网的方式录入数据源，然后单击“创建数据源”完成创建。重复此步骤，完成源数据源和目标数据源的录入-3。

3.2 第二步：配置同步链路

登录NineData控制台，单击“数据复制”>“数据复制”，然后单击“创建复制”。根据页面提示配置复制任务，为保证完整将源端的全量数据和增量数据迁移至目标端，需要在复制类型处勾选结构复制、全量复制和增量复制-3。

配置完成后启动任务，针对您配置的所有同步对象，NineData会先对所有的存量数据进行全量迁移，接下来就是实时迁移源端中新增的增量数据，所有新写入的数据都将一条不漏地同步到目标端-3。

3.3 第三步：校验数据完整性

除了同步功能以外，NineData还提供了同步后源端和目标端同步数据的对比功能，以确保目标端数据的完整性。登录NineData控制台，单击数据复制>数据复制，然后单击步骤二中创建的复制任务ID。单击“数据对比”页签，即可展示对比结果-3。

3.4 第四步：配置异常告警

由于是长期任务，您可能需要系统实时监控任务状态，在任务有异常时即刻通知您。单击复制任务ID，单击右上角的“配置告警”。输入策略名称，单击保存配置即可。您可以直接使用内置的默认规则，在任务运行失败，或复制延迟大于等于10分钟的时候，发送短信提醒您-3。

四、两种应用场景

4.1 一次性迁移

通过上述步骤，您即可完整地将业务数据从其他云迁移到GCP Cloud SQL MySQL。在增量复制延迟为0的前提下，您可以在任何您需要的时间进行业务割接，把业务流量切换到新的云上-3。

4.2 长期多活

如果您只是需要将GCP Cloud SQL MySQL作为一个业务的多活节点，也可以保留该条迁移链路持续运行，NineData会保证两端的数据实时保持一致-3。

结语

至此，您已成功实现了跨云厂商的不停机数据库迁移，最大程度地减少了对线上业务的影响。这套方案的核心价值在于：安全（无需开启公网）、高效（200GB/小时）、可靠（完整回滚方案），真正解决了跨云迁移的难题-3。