前言

随着互联网业务发展对容灾以及对访问加速、多供应商成本控制等需求的产生，互联网公司的多云部署和跨云迁移逐渐成为刚需，而在此过程中，最困扰运维和研发人员的就是数据的迁移和同步。俗语说“ 上屋搬下屋，搬洒一箩谷 ”，在业务的迁移过程中一旦遇到重要数据的丢失，将会对企业造成巨大的损失。

UCloud优刻得通过对一些客户的跨云迁移过程进行总结，发现普遍存在的挑战有三点：

> 数据完整性和一致性挑战。

> 时效性，即迁移窗口期相对有限。

> 应用依赖性和各种调用关系。

跨云迁移涉及到的资源主要分成三大类：

第一类是EIP、VPC、负载均衡和NAT网关这类网络服务，在跨云迁移的过程中这些都会发生变化，而且是无状态服务，配置并不复杂，对于这部分资源可以通过人工的方法对齐配置。

第二类是最为常见的云主机资源，这部分我们可以通过UCloud优刻得服务器迁移工具USMC，以相同的配置在UCloud优刻得公有云上创建一份，只需保持和源端服务器IP一致的目标端服务器IP，支持按分钟级别进行增量数据同步，减少业务切换的时间。

而第三类就是包括数据库、文件存储和对象存储在内的一些存储服务，我们可以通过UDTS数据传输工具进行迁移，而这一部分也正是本文重点讨论的实践内容。

通常，我们将跨云迁移划分为三个阶段： 数据同步阶段、数据规整阶段(清理测试时产生的脏数据)和数据割接阶段。数据同步阶段主要是需要解决两个问题，首先是将数据复制到新平台，并且让应用程序在新平台运行，这也是跨云迁移的核心；其次就是利用真实数据对应用程序进行测试，确认应用程序在目标平台可以符合预期地运行。我们知道数据可以分为结构化数据和非结构化数据，用来存储数据的方法众多，本文主要介绍数据同步阶段中常见的存储组件例如MySQL、文件存储和对象存储的数据迁移实践。其它不同的存储组件各有不同，但也是可以参考这几个组件的迁移逻辑来处理的。

MySQL同步

一般来说，我们认为对于MySQL的同步，只要存量数据和增量数据都能做到一致，那么整个数据库的同步就是一致的。而常见的MySQL数据迁移方式有两种：一种是基于MySQL主从的方式，通过mysqldump记录下binlog位置，然后把这个binlog位置前的数据完整导出，恢复出一个备库，然后再从记录的binlog位置开始向主库追平增量数据。

另一种就是UDTS工具，总体上也是分为存量阶段和增量阶段，增量阶段的追及是将从存量同步发起的一瞬间开始往后的数据变化通过binlog的形式同步到目标库。增量同步依靠binlog完成，这是MySQL主从同步的基础，是我们需要默认信任的数据一致性机制，当然我们最终需要以数据校验结果来确认数据是否一致。简而言之， 跨云迁移过程中MySQL的数据一致性主要就集中在存量数据的迁移如何保证一致。

【案例】

以近期的xx公司迁移到UCloud为例，其涉及数据库实例有数十个，并且由于应用依赖的原因需要进行整体迁移。在这案例中，如果采用mysqldump的方法，那么这数十个数据库都需要经过导出、传输、导入和配置主从这样的操作，给整个迁移任务增加了不少工作量。