跨云迁移过程中的数据一致性实践

这篇博客介绍了跨云迁移过程中如何保证数据一致性,主要包括数据同步、数据规整和数据割接三个阶段。在数据同步阶段,重点关注MySQL、文件存储和对象存储的数据迁移与校验,如MySQL的增量同步和基于binlog的数据一致性。数据规整阶段涉及脏数据处理和数据一致性的保障措施,如数据库只读、结束应用进程和网络ACL隔离。数据割接阶段则讨论了最佳的数据校验时机和回滚策略。整个实践旨在确保在有限的业务暂停时间内完成高效且一致的跨云迁移。
摘要由CSDN通过智能技术生成
随着互联网业务发展和对容灾的需求,以及对访问加速、多供应商成本控制等要求,互联网公司通过跨云部署和迁移来更好的控制成本逐渐成为刚需,跨云部署和迁移也就成为运维圈子里的一个热门话题,而在此过程中,对运维和研发最头痛就是数据的迁移和分布。

粤语中有一句谚语“上屋搬下屋,搬洒一箩谷”,意思是在各种各样的搬动过程中,或多或少都会伴随一些资产的流失,这对于互联网业务来说是难以接受的。

通过对最近几次客户的多云部署进行总结,过程中存在的挑战有三点:

首先是数据完整性和一致性挑战。

其次是时效性,迁移窗口期相对有限。

再者是依赖性和各种访问关系。

在大多数实际环境中都存在着应用依赖性,如何万千关系中理顺每条访问关系也是让人望而却步的事情。

跨云迁移涉及到的资源一般可以分成三大类:

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

接下来是最为常见的云主机资源,这部分我们可以通过USMC服务器迁移工具来进行迁移,对于一些例如zookeeper的服务,也可以通过人手同步配置的方式来迁移。

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

 

跨云迁移

在这些客户的多云部署和迁移过程中,如何在有限的业务暂停时间里,将大量数据进行迁移,并且保证数据一致,有了较多实践和沉淀。为给大家提供有效的借鉴意义,花了一些时间从实践总结了共性,将跨云迁移划分为三个阶段:数据同步阶段、数据规整阶段(清理测试产生脏数据)和数据割接阶段进行阐述。

1. 数据同步阶段

数据同步阶段主要是需要解决两个问题,其中最主要的还是跨云迁移的核心,即将数据复制到新平台,并且让应用程序在新平台运行,其次就是利用真实数据对应用程序进行测试,确认应用程序在目标平台可以符合预期地运行。我们都知道数据可以分为结构化数据和非结构化数据,用来存储数据的方法众多,无法逐个深入分析,所以笔者在这里只提供一些最常见的存储组件的迁移实践,其它不同的存储组件各有不同,但也是可以参考这几个组件的迁移逻辑来处理的。

下面将分别讨论MySQL、文件存储和对象存储的数据同步方式。

1.1 MySQL同步

一般来说,我们认为对于MySQL的同步,只要存量数据和增量数据都能做到一致,那么整个数据库的同步就是一致的。

而常见的MySQL数据迁移方式有两种:一种是基于MySQL主从的方式,通过mysqldump记录下binlog位置,然后把这个binlog位置前的数据完整导出,恢复出一个备库,然后再从记录的binlog位置开始向主库追平增量数据。另一种就是UDTS工具,但总体上也是分为存量阶段和增量阶段,增量阶段的追及是将从存量同步发起的一瞬间开始往后的数据变化通过binlog的形式同步到目标库。

增量同步依靠binlog完成,这是MySQL主从同步的基础,是我们需要默认信任的数据一致性机制,所以反过来说,如果我们不信任MySQL的binlog机制,那么其它MySQL的数据一致性机制也是需要怀疑的,包括数据落地的fsycn()调用是否真正的把数据写入到磁盘和事务等等,这样就陷入了怀疑论了。当然我们最终需要以数据校验结果来确认数据是否一致。

简而言之,跨云迁移过程中MySQL的数据一致性主要就集中在存量数据的迁移如何保证一致。

【案例】

以近期的xx公司迁移到UCloud为例,其涉及数据库实例有数十个,并且由于应用依赖的原因需要进行整体迁移。在这案例中,如果采用mysqldump的方法,那么这数十个数据库都需要经过导出、传输、导入和配置主从这样的操作,给整个迁移任务增加了不少工作量。同时也正如很多商业智能应用需要将数据汇总用作分析,他们业务系统也有类似的汇总数据库,这种级联关系会让数据同步操作进一步复杂化。最终客户使用了UDTS作为跨云数据同步的解决办法,在保障数据一致的同时,DBA只需要提供两边数据库的连接和账号信息即可将数据同步任务托管,释放了精力去处理业务上的数据库工作需求。

1.1.1 数据同步

前面提到MySQL事务,在理解存量数据迁移过程中的数据一致性时,需要先了解InnoDB为代表的事务引擎和MyISAM代表的非事务引擎。使用MyISAM引擎的数据表确实没有很好的数据一致性确保手段,存量数据只能对数据表加读锁并迁移,在完成存量数据同步后,通过binlog追平,这样因为读锁会阻塞数据的写入,会导致业务的写入功能不可用,而且这一不可用的时间视表中数据体量而定。

幸而因为MyISAM的不灵活,实际互联网公司中已经很少使用MyISAM引擎了。而InnoDB引擎因为它支持事务和行级锁的特性,在数据同步过程中对业务的影响小很多,但也因此对数据一致性的保护方法也相对复杂,而这一套一致性保护方法,核心就在于基于连接session的事务隔离和基于MVCC的数据版本管理。

在存量数据同步启动的时候,数据迁移工具会在自己对数据库的连接session上设置事务隔离级别为REPEATABLE READ,自动提交设置关闭࿰

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值