MySQL安全高效迁移GCP Cloud SQL MySQL，NineData 跨云迁移方案揭秘

关注

原创 2024-06-17 14:45:13 1.1k 阅读 AI 写同款· GEO 优化 ›

在云厂商众多的当前市场环境下，各种云在售价、性能、功能、售后等方面都存在较大的差距，很难找到一朵在所有方面都最佳的云，因此，跨云迁移成了许多企业的选择，而本次我们的迁移目标是 Google 的 GCP Cloud SQL MySQL。

先来看下为什么要选 GCP

GCP Cloud SQL 是 Google Cloud Platform（GCP）提供的全托管关系型数据库服务。它提供了可靠、安全的数据库服务，支持基于负载的弹性伸缩，同时提供自动故障转移功能，保证数据库的高可用性，让开发人员专注于应用程序开发，无需再担心底层数据库的各种问题。

换句话说，你只需要掏钱，剩下的交给 GCP，看上去还是挺靠谱的，另外由于是谷歌的产品，想必是有保障的。

跨云迁移存在哪些问题？

我们要做的是跨云迁移，听上去好像很简单，但是实际操作起来还是挺复杂的，由于大部分云厂商提供的配套迁移产品只进不出，即只针对自建库上自身云提供了良好的支持，但对于从自身云迁出的需求，往往无法满足。

出于安全性方面考虑，云数据库通常是封闭的内网环境，在配套迁移产品无法提供迁出支持的前提下，想要迁移数据必须得开启公网访问地址，而这一举动无疑给不法分子提供了攻击数据库的绝佳良机，等待企业的可能会是数据库被攻陷，重要的数据遭到泄露，更有甚者数据直接被清空，多年的经营成果毁于一旦。

除此之外，还有一系列不得不考虑的问题：

业务的可用性：迁移必须在不影响业务的前提下进行，换句话说，迁移时不能停机，那需要考虑的事情就非常多了：存量和增量数据如何完整迁移？如何处理迁移时的性能波动？如何实现应用程序的平滑切换？等等。
表结构初始化及变更联动：当待迁移表数量巨大，且迁移过程中源库发生 DDL 操作的情况下，如何实现高效且稳定的数据库迁移无疑是一大挑战。
迁移数据质量：大规模数据搬迁过程中，如何保障数据一致性；当业务迁移切换异常情况下，如何有效回滚保障业务的可用性。
迁移失败如何止损：不同的云在功能与性能上表现迥异，迁移复杂度较高，当业务出现迁移失败的情况下，如何有效保障业务的可用性也是业务需要考虑的重点问题。

因此，我们需要一个不用开公网、功能全面、稳定、快速、实时监控迁移任务状态，并且保证迁移结果一致性的工具。

怎么解决跨云迁移问题？

那么它说来就来了，NineData 的数据复制功能专门针对上述痛点设计，我们先来看看 NineData 的一些特性：

1. 多云厂商支持

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

2. 迁移过程业务不停机

NineData 提供结构迁移、全量数据迁移及基于 redo log 的 CDC 增量数据迁移能力。在数据库迁移过程中，源端 oracle 可正常提供服务。NineData 可自动完成结构迁移、全量数据迁移，并自动启动 redo log 的实时监听、采集、解析及复制能力，对于源端的增量更新数据会被实时复制到目标端中。

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

2. 强劲的复制性能

在数据库迁移过程中，迁移速度无疑是影响业务能否成功切换割接的重要因素。NineData 基于日志分析、智能分片、动态攒批、数据合并、特有数据格式等技术，有效保障全量数据复制、增量数据复制的性能。当前 NineData 全量复制性能高达 200 GB/小时，增量数据复制性能高达 2 万记录/秒。

4. 完善的迁移回滚方案

不同云数据库之间在功能、性能上相差较多，涉及大量的业务改造及性能调优，迁移割接的难度极高。为降低割接失败的风险，通常业务都需要做好割接失败的回滚预案。NineData 提供了 CDC 增量复制能力，支持从源端实时采集、解析日志并同步增量至目标端。

当业务从源端切换到目标端之前，可以在 NineData 搭建一条从目标端实时回流增量数据至源端的复制任务。基于此复制任务，可以将业务割接完成后产生的新数据同步回流至源端，使源端保留完整的业务数据。一旦出现因目标端的功能或性能导致的业务运行问题，可随时将业务回切回源端，有效规避业务迁移故障。

基于上述能力，NineData 可轻松解决不同云厂商之间的迁移问题，下面来看看怎么操作。