21世纪了还愚公移山?数据库这么迁移更稳定!

  • 时间:
  • 浏览:4

Photo by Barth Bailey on Unsplash

在系统的快速迭代过程中,业务系统往往部署在同一三个 物理库,没办法 做核心数据和非核心数据的物理隔离。随着数据量的扩大这一 情况表会带来稳定性的风险,如库的慢sql,磁盘,IO等等都不 相互整体影响,从而影响核心系统的业务稳定性,后来必须将核心业务的业务表从原有库里抽取出来,单独到新库里。而核心数据的迁移,涉及到的一三个 关键难点:怎么都可以平稳及用户无感知的迁移数据,本文将结合闲鱼商品库迁移实践,向我们我们展示怎么都可以补救这一 问题 的。

闲鱼商品数据现状

闲鱼商品数据量XX亿级别以上, 采用分表分库和读写分离的MYSQL数据库集群来支撑线上查询服务,如下图,通过TDDL[1]数据库上面件进行高效统一管理。机会许多同学好对分表分库相关概念不了解,这里先简单做些介绍。

01分表分库原理

本质是数据库的水平拆分问题 ,把一三个 数据库切分成多个累积放在不同的数据库(server)上,从而缓解单一数据库的性能问题 ,下图描述分表分库的核心原理:



当然分表分库详细都不 负面影响,后来表价值形式变更及相关管理相比单表麻烦,有一定风险,具体怎么都可以决择,还是要根据实际情况表来分析。

02分表分库下全局Sequence生成

分表分库补救在线服务容量和性能问题 ,后来也带来使用上的错综复杂度提升。灵活的配置路由规则和路由数据并提供简单易用的封装详细都不 要考虑的,以便业务对此无感知。阿里开源上面件产品TDDL提供了补救方案,对应阿里云上产品为:DRDS[2]。

TDDL关键原理太满做介绍,后来在数据库迁移过程中主键冲突风险是故障重要风险点,这里简要介绍下TDDL的全局唯一主键生成原理。



如上图,TDDL Sequence是基于数据库更新+内存分配:每次操作批量分配id,分配id的数量后来sequence的内步长,而原有id值就去掉 内部内部结构长值,后续的分配直接就在内存里拿,另一三个 的优势:简单高效 缺点:无法保证自增顺序。

另外数据迁移过程中,在新库中,为了保证跟原数据库主键非冲突,必须设置一三个 跃迁比较大的主键,补救总是出现三个 库中的主键冲突,这是后续迁移中要注意的关键点之一。

数据迁移方案

通过前文的简单介绍,我们我们对闲鱼商品库现状有了初步了解,下面将给我们我们介绍一下闲鱼是怎么都可以做到稳定迁移商品库的。

01核心思路

数据迁移核心思路抽象起来虽然很简单,即怎么都可以稳定平滑迁移数据,如下图所示:

但围绕这一 过程细化下去,我们我们会遇到不少问题 ,如:

1、数据我们我们该怎么都可以迁移,是一次性?还是分阶段?

2、怎么都可以校验数据迁移过程的正确性?

3、我们我们业务改造有问题 为什么办?怎么都可以尽早发现?怎么都可以回滚?

4、我们我们的新库性能怎么都可以?

带着有有哪些问题 ,我们我们进一下细化梳理迁移方案。

02实现方案

如上图所示,整个方案分为十2个 部份:

1、系统改造,包括SQL改造,双写开关,新库sequence创建。

SQL改造:加载两套TDDL数据源,一套是给老库的,一套是给新库的,后来生成两套mybatis sql 模板。

双写开关:设置好写新库,写老库的开关,用于线上迁移过程中双写过程及遇到问题 及时回滚。

sequence创建:迁移sequence表时,必须抬升新库的sequence表中的值,用于补救主键冲突,后来必须按照主键消耗量评估一三个 安全值,这是非常重要的一三个 细节,再次强调一下。

2、稳定性保障,迁库是大事,改造过程中,稳定性重中之重,主要有系统压测,线上流量回放,故障演练。

系统压测:主要针对新库进行性能测,补救新库有意外情况表。

线上流量回放:Edsger W. Dijkstra说过机会调试守护进程是并不是 标准的才能铲除BUG的流程,没办法 ,编程后来把我们我们放在来的流程。通过引入线上数据在测试环境回放,才能尽机会的发现问题 ,保证改造后的稳定性。

故障演练:通过注入其他同学为故障,如写新库失败,新库逻辑有问题 ,及时的演练回滚策略。

3、数据迁移,主要利用阿里云数据传输服务DTS[3]的数据迁移能力,涉及到全量迁移、增量迁移、一致性校验及反向任务。

全量迁移:数据迁移首要目标怎么都可以将历史全量数据迁移到新库中,我们我们的做法是指定一三个 时间点,再根据这一 时间点查找每张源表的最大及最小id,后来分别批量导到目标库中,如图:

*整个过程详细都不 查询在线库的备库,后来不影响在线业务的数据库服务。

增量迁移:机会迁移过程中业务服务总是运行,后来全量迁移详细成,后来要将全量时间点后的数据追回来,这里核心原理是同步全量时间位点后binlog日志数据来保证数据一致性,必须注意的是增量时间必须前移一小断时间(如5分钟),其主要意味分析是全量迁移启动的那刻会有时间差,必须增量前移来保证数据最终一致性,如下图:

一致性校验:通过全量及增量的迁移后,此时源库跟目标的数据理论上是一致的,但实际上应用在经过功能测试,线上流量回放等阶段,数据在这一 过程带有机会会现不一致的情况表,后来正式上线前,必须做数据一致性校验,其原理是分批查询源表(跟全量迁移的查询依据之类于),再跟目标库进行比对,如图所示:

反向任务:迁移到新库后,会有一线离线业务对老库还有依赖,必须建立从新库到老库的回流任务,原理跟增量迁移一样,后来变更一下原库及目标库。

03迁库流程

到这里我们我们应该对迁库所涉及到点比较清楚了,但还有一三个 非常重要的事,即梳理整个迁库步骤非常关键,通常会有并不是 方案。

方案一:

1、DTS数据追平,即全量同步完成,开启增量同步,后来延迟在秒级以内。

2、上线前校验,主要有线上流量回放、压测、一致性校验,故障演练。

3、线上开双写,线上同時 写新库及老库,这时必须关闭增量同步任务,补救无效覆盖。

4、线上校验,执行预先准备的测试脚本并结合一致性校验工具,同時 将读流量慢慢切到新库,验证双写逻辑。

5、切换数据源,关闭双写并正式写入新库。

6、创建反向任务,数据回流老库。

方案二:



1、DTS数据追平,即全量同步完成,开启增量同步,后来延迟在秒级以内。

2、上线前校验,主要有线上流量回放、压测、一致性校验,故障演练。

3、线上切开关,写新库, 同時 必须关闭增量同步任务,补救无效覆盖。

4、创建反向任务,数据回流老库。

方案优缺点对比:

总结起来方案1迁移流程相对错综复杂,对迁移的控制力度更细,适合业务错综复杂,底层改造比较多,想精细化控制迁移步骤的场景,方案2迁移相对简单,过程快速,适合业务流程相对简单,可控,想快速切换的场景,具体选选着哪个方案,同学们才能根据自身的业务情况表做选着。

这里考虑到闲鱼商品业务错综复杂,底层改造较多,从稳定性的角度考虑,最终选着方案1。

方案1,最关键的是3、4、5步骤,后来必须预先做好回滚计划。

04回滚方案

回滚方案总原则是不丢数据。最有机会的位于点是双写期间新库出问题 ,意味分析线上服务异常,这时假使 立即关闭写新库即可,另外后来切到新库后,新库出问题 了(如性能问题 ),才能立即切回到老库,并通过反向任务,保持数据一致性,最后若没启用分布式事务,双写的时间越短越好,有机会会有数据不一致情况表。

小结

通过周密的迁移方案设计,以及DTS强大的数据迁移工具的能力,闲鱼商品库顺利完成XX亿在线数据库服务迁移,独立的物理部署显著提升商品库在线服务的稳定性。然而不同业务系统的数据库情况表机会会有差异,如单库向多库迁移,单表向多表迁移等,不过整体方案大致之类于,希望本文迁库实践方案能给我们我们提供一三个 可行的参考。

本文由

闲鱼技术

发布在

ITPUB

,转载此文请保持文章详细性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/07/16/2429/