如何将 MySQL 数据源不停机迁移到 AWS RDS MySQL
就在近期，谷歌云捅了个大篓子，误删除了一家投资公司（Unisuper，管理着800亿美元基金）在谷歌云所有地域的所有数据，删得相当彻底，连备份数据都没给人家留一个。
Unisuper 是一家澳大利亚退休金基金，为澳大利亚高等教育和研究部门的员工提供退休金服务。截至 2023 年 6 月 30 日，该基金拥有超过 615,000 名会员，管理着 1,240 亿澳元（800亿美金）的基金。
事件直接导致了 Unisuper 的该基金服务全面瘫痪，截止今日（5 月 12 日）已逾一周，60 万会员的 800 亿美元无法支取。幸运的是，Unisuper 公司事前就考虑过可能存在的风险，并没有把自己吊死在一棵树上，而是在谷歌云之外的其他云上也保留了数据备份，此举直接挽救了他们的基金业务，让系统有了可恢复的余地。
本次事件在业界引发了针对云计算服务提供商数据安全性的广泛关注和担忧，虽然云计算为企业提供了灵活性和便利性，但是将业务数据保管在一朵云上是非常不安全的。对于 Unisuper 这样的大型金融机构来说，本次事件造成的信用和声誉影响将会非常深远，客户也会产生诸如此类的疑问：“我的钱安全吗？”、“我的信息安全吗？”、“我凭什么相信这种事件不会再次发生？”。
如何防止云厂商一键删库？
虽然发生的概率不大，但一经发生，对企业将会是致命打击。本次谷歌云事件无疑为所有在云上托管业务的企业和组织敲响了警钟，他们不得不重新审视一个问题，那就是如何确保企业的命脉：业务数据的安全性。
我们今天要讨论的解决方案，就是 Unisuper 采用的多云策略，但是 Unisuper 采取的多云策略其实是有缺陷的。
由于 Unisuper 仅仅在其他云上保留了备份数据，并且可能该备份数据并不是实时数据，因此后续花了一周多的时间才完成恢复。
而我们要采取的是更加完善的多云策略，即在其他云上维护一个数据库实例，通过一条实时同步链路实时将主库的数据源源不断地同步到该数据库实例中，保证两端数据在任何时候都是一致的。
要实现该策略，那就需要把当前云环境中的数据迁移到另一朵云，作为示例，我们本次的迁移目标，是 AWS 的 RDS MySQL。
为什么要选 AWS
Amazon Web Services（AWS）是全球最全面、应用最广泛的云，从全球数据中心提供超过 200 项功能齐全的服务（摘自 AWS 官网）。
选择 AWS RDS MySQL 作为本文示例的其中一个原因，是 AWS 的安全性，AWS 的核心基础设施是为了满足军事、全球的银行和其他高度敏感性组织的安全要求而构建的。并且 AWS 支持 90 个安全标准和合规性认证，而且存储客户数据的所有 AWS 服务均具有加密数据的能力。
跨云迁移存在哪些问题？
我们要做的是跨云迁移，听上去好像很简单，但是实际操作起来还是挺复杂的，由于大部分云厂商提供的配套迁移产品只进不出，即只针对自建库上自身云提供了良好的支持，但对于从自身云迁出的需求，往往无法满足。
出于安全性方面考虑，云数据库通常是封闭的内网环境，在配套迁移产品无法提供迁出支持的前提下，想要迁移数据必须得开启公网访问地址，而这一举动无疑给不法分子提供了攻击数据库的绝佳良机，等待企业的可能会是数据库被攻陷，重要的数据遭到泄露，更有甚者数据直接被清空，多年的经营成果毁于一旦。
除此之外，还有一系列不得不考虑的问题：
- 业务的可用性：迁移必须在不影响业务的前提下进行，换句话说，迁移时不能停机，那需要考虑的事情就非常多了：存量和增量数据如何完整迁移？如何处理迁移时的性能波动？如何实现应用程序的平滑切换？等等。
- 表结构初始化及变更联动：当待迁移表数量巨大，且迁移过程中源库发生 DDL 操作的情况下，如何实现高效且稳定的数据库迁移无疑是一大挑战。
- 迁移数据质量：大规模数据搬迁过程中，如何保障数据一致性；当业务迁移切换异常情况下，如何有效回滚保障业务的可用性。
- 迁移失败如何止损： 不同的云在功能与性能上表现迥异，迁移复杂度较高，当业务出现迁移失败的情况下，如何有效保障业务的可用性也是业务需要考虑的重点问题。
因此，我们需要一个不用开公网、功能全面、稳定、快速、实时监控迁移任务状态，并且保证迁移结果一致性的工具。
怎么解决跨云迁移问题？
那么它说来就来了，NineData 的数据复制功能专门针对上述痛点设计，我们先来看看 NineData 的一些特性：
- 多云厂商支持：集成各个云厂商的私网环境，迁移无需在云数据库端开启公网访问链接，对于比较不常见的云厂商，还提供了网关功能，同样可以免开公网直接访问到数据库，让迁移链路安全又高效。
- 迁移过程业务不停机：NineData 提供结构迁移、全量数据迁移及基于 redo log 的 CDC 增量数据迁移能力。在数据库迁移过程中，源端 oracle 可正常提供服务。NineData 可自动完成结构迁移、全量数据迁移，并自动启动 redo log 的实时监听、采集、解析及复制能力，对于源端的增量更新数据会被实时复制到目标端中。当 NineData 进入到增量数据迁移阶段且复制无延迟时，业务可以在目标端中进行只读验证，并借助 NineData 数据对比工具进行数据一致性验证。业务验证通过后，可进行业务停机切换。由此可见，整个迁移过程业务停机时间非常短。
- 强劲的复制性能：在数据库迁移过程中，迁移速度无疑是影响业务能否成功切换割接的重要因素。NineData 基于日志分析、智能分片、动态攒批、数据合并、特有数据格式等技术，有效保障全量数据复制、增量数据复制的性能。当前 NineData 全量复制性能高达 200 GB/小时，增量数据复制性能高达 2 万记录/秒。
- 完善的迁移回滚方案：不同云数据库之间在功能、性能上相差较多，涉及大量的业务改造及性能调优，迁移割接的难度极高。为降低割接失败的风险，通常业务都需要做好割接失败的回滚预案。NineData 提供了 CDC 增量复制能力，支持从源端实时采集、解析日志并同步增量至目标端。当业务从源端切换到目标端之前，可以在 NineData 搭建一条从目标端实时回流增量数据至源端的复制任务。基于此复制任务，可以将业务割接完成后产生的新数据同步回流至源端，使源端保留完整的业务数据。一旦出现因目标端的功能或性能导致的业务运行问题，可随时将业务回切回源端，有效规避业务迁移故障。
基于上述能力，NineData 可轻松解决不同云厂商之间的迁移问题，下面来看看怎么操作。
步骤一：录入源和目标数据源
登录 NineData 控制台，单击数据源管理>数据源，然后在页面中单击创建数据源，选择需要的云厂商。
根据页面提示，通过私网的方式录入数据源，然后单击创建数据源完成创建。重复此步骤，完成源数据源和目标数据源的录入。
步骤二：配置同步链路
登录 NineData 控制台，单击数据复制>数据复制，然后单击创建复制。
根据页面提示配置复制任务，为保证完整将源端的全量数据和增量数据迁移至目标端，需要在复制类型处勾选结构复制、全量复制和增量复制。
配置完成后启动任务，针对您配置的所有同步对象，NineData 会先对所有的存量数据进行全量迁移，接下来就是实时迁移源端中新增的增量数据，所有新写入的数据都将一条不漏地同步到目标端，每当目标端的增量数据追平源端时，任务面板中会显示延迟 0 秒，代表当前目标端中的数据是最新的。
步骤三（可选）：校验目标端同步数据的完整性
除了同步功能以外，NineData 还提供了同步后源端和目标端同步数据的对比功能，以确保目标端数据的完整性。
登录 NineData 控制台，单击数据复制>数据复制，然后单击步骤二中创建的复制任务 ID。
单击数据对比页签，即可展示对比结果（如果步骤二的任务配置中未勾选开启数据一致性对比，则此处还需要单击开启数据对比）。
您可以在一段时间后，单击页面中的重新对比，校验最新增量数据的同步结果。
步骤四（可选）：配置任务异常告警
由于是长期任务，您可能需要系统实时监控任务状态，在任务有异常时即刻通知您。
登录 NineData 控制台，单击数据复制>数据复制，然后单击步骤二中创建的复制任务 ID。
单击右上角的配置告警。
输入策略名称，单击保存配置即可。您可以直接使用内置的默认规则，在任务运行失败，或复制延迟大于等于 10 分钟的时候，发送短信提醒您。您也可以自定义创建规则，根据您的需求来进行通知。
总结
通过上述步骤，您即可完整地将您的业务数据从其他云迁移到 AWS RDS MySQL，在增量复制延迟为 0 的前提下，您可以在任何您需要的时间进行业务割接，把业务流量切换到新的云上。
如果您只是需要将 AWS RDS MySQL 作为一个您业务的多活节点，也可以保留该条迁移链路持续运行，NineData 会保证两端的数据实时保持一致，在其中一个云厂商出现故障后，可以迅速将业务切换到另一个云。
至此，您已成功实现了跨云厂商的不停机数据库迁移，最大程度地减少了对线上业务的影响。