侧边栏壁纸
博主头像
汪洋

即使慢,驰而不息,纵会落后,纵会失败,但一定可以达到他所向的目标。 - 鲁迅

  • 累计撰写 192 篇文章
  • 累计创建 74 个标签
  • 累计收到 120 条评论

MySQL 千亿级数据线上平滑扩容实战 - 5 大主流方案对比

汪洋
2023-03-27 / 0 评论 / 2 点赞 / 472 阅读 / 3,178 字

在项目初期,我们部署了三个数据库 A、B、C,此时数据库的规模可以满足我们的业务需求。为了将数据做到平均分配,我们在 Service 服务层使用 uid%3 进行取模分片,从而将数据平均分配到三个数据库中。

如图所示

后期随着用户量的增加,用户产生的数据信息被源源不断的添加到数据库中,最终达到数据库的最佳存储容量。如果此时继续向数据库中新增数据,会导致数据库的 CRUD 等基本操作变慢,进而影响整个服务的响应速度。

这时,我们需要增加新的节点,对数据库进行水平扩容,那么加入新的数据库 D 后,数据库的规模由原来的 3 个变为 4 个。

如图所示:
mysql52.png

此时由于分片规则发生了变化(uid%3 变为 uid%4),导致大部分的数据,无法命中原有的数据,需要重新进行分配,要做大量的数据迁移处理。

比如之前 uid 如果是 uid=3 取模 3%3=0, 是分配在 A 库上,新加入 D 库后, uid=3 取模 3%4=3,分配在 D 库上;

mysql53.png

新增一个节点, 大概会有 90% 的数据需要迁移, 这样会面临大量的数据压力,并且对服务造成极大的不稳定性。

五个方案

1.1 停机方案

mysql54.png

1、发布公告:为了进行数据的重新拆分,在停止服务之前,我们需要提前通知用户,比如:我们的服务会在 yyyy-MM-dd 进行升级,给您带来的不便敬请谅解。
2、停止服务:关闭 Service
3、离线数据迁移(拆分,重新分配数据):将旧库中的数据按照Service 层的算法,将数据拆分,重新分配数据
4、数据校验:开发定制一个程序对旧库和新库中的数据进行校验,比对
5、更改配置:修改 Service 层的配置算法,也就是将原来的 uid%3 变为 uid%4
6、恢复服务:重启 Service 服务
7、回滚预案:针对上述的每个步骤都要有数据回滚预案,一旦某个环节(如:数据迁移,恢复服务等)执行失败,立刻进行回滚,重新再来

1.2 停写方案

mysql55.png

1、支持读写分离:数据库支持读写分离,在扩容之前,每个数据库都提供了读写功能,数据重新分配的过程中,将每个数据库设置为只读状态,关闭写的功能
2、升级公告:为了进行数据的重新拆分,在停写之前,我们需要提前通知用户,比如:我们的服务会在 yyyy-MM-dd 进行升级,给您带来的不便敬请谅解
3、中断写操作,隔离写数据源(或拦截返回统一提示):在 Service 层对所有的写请求进行拦截,统一返回提示信息,如:服务正在升级中,只对外提供读服务
4、数据同步处理:将旧库中的数据按照 Service 层的算法,将数据重新分配,迁移(复制数据)
5、数据校验:开发定制一个程序对旧库中的数据进行备份,使用备份的数据和重新分配后的数据进行校验,比对
6、更改配置:通过配置中心,修改 Service 层的配置算法,也就是将原来的 uid%3 变为 uid%4,这个过程不需要重启服务
6、恢复写操作:设置数据库恢复读写功能,去除 Service 层的拦截提示
7、数据清理:使用delete语句对冗余数据进行删除
8、回滚预案:针对上述的每个步骤都要有数据回滚预案,一旦某个环节(如:数据迁移等)执行失败,立刻进行回滚,重新再来

缺点:在数据的复制过程需要消耗大量的时间,停写时间太长,数据需要先复制,再清理冗余数据

1.3 日志方案

核心是通过日志进行数据库的同步迁移, 主要操作步骤如下:

1、数据迁移之前, 业务应用访问旧的数据库节点

mysql56.png

2、日志记录

在升级之前, 记录“对旧数据库上的数据修改”的日志(这里修改包括增、删、改),这个日志不需要记录详细的数据信息,主要记录:

  • 修改的库
  • 修改的表
  • 修改的唯一主键
  • 修改操作类型

mysql57.png

日志记录不用关注新增了哪些信息,修改的数据格式,只需要记录以上数据信息,这样日志格式是固定的, 这样能保证方案的通用性。

服务升级日志记录功能风险较小:

写和修改接口是少数, 改动点少;升级只是增加了一些日志,采用异步方式实现, 对业务功能没有太多影响。

3、数据迁移

研发定制数据迁移工具, 作用是把旧库中的数据迁移至新库中。

mysql58.png

整个过程仍然采用旧库进行对外服务。
数据同步工具实现复杂度不高。
只对旧库进行读取操作, 如果同步出现问题, 都可以对新库进行回滚操作。
可以限速或分批迁移执行, 不会有时间压力。

数据迁移完成之后, 并不能切换至新库提供服务。

因为旧库依然对线上提供服务, 库中的数据随时会发生变化, 但这些变化的数据并没有同步到新库中, 旧库和新库数据不一致, 所以不能直接进行切换, 需要将数据同步完整。

4、日志增量迁移

image.png

研发一个日志迁移工具,把上面迁移数据过程中的差异数据追平,处理步骤:

读取 log 日志,获取具体是哪个库、表和主键发生了变化修改;把旧库中的主键记录读取出来; 根据主键 ID,把新库中的记录替换掉

这样可以最大程度的保障数据的一致性。风险分析:

整个过程, 仍然是旧库对线上提供服务;日志迁移工具实现的复杂度较低;任何时间发现问题,可以重新再来,有充分的容错空间;可以限速重放处理日志,处理过程不会因为对线上影响造成时间压力。

但是, 日志增量同步完成之后, 还不能切换到新的数据库。

因为日志增量同步过程中,旧库中可能有数据发生变化,导致数据不一致,所以需要进一步读取日志,追平数据记录;日志增量同步过程随时可能会产生新的数据, 新库与旧库的数据追平也会是一个无限逼近的过程。

5、数据校验

准备好数据校验工具,将旧库和新库中的数据进行比对,直到数据完全一致。

image.png

6、切换新库

数据比对完成之后, 将流量转移切换至新库, 至此新库提供服务, 完成迁移。

image.png

但是在极限情况下, 即便通过上面的数据校验处理, 也有可能出现 99.99% 数据一致,不能保障完全一致,这个时候可以在旧库做一个 readonly 只读功能, 或者将流量屏蔽降级,等待日志增量同步工具完全追平后,再进行新库的切换。

至此,完成日志方案的迁移扩容处理,整个过程能够持续对线上提供服务,只会短暂的影响服务的可用性。

这种方案的弊端,是操作繁琐,需要适配多个同步处理工具,成本较高,需要制定个性化业务的同步处理, 不具备普遍性,耗费的时间周期也较长。

1.4 双写方案(中小型数据)

image.png

双写方案可通过 canal 或 mq 做实现。

  • 增加新库,按照现有节点, 增加对应的数量。
  • 数据迁移:避免增量影响, 先断开主从,再导入(耗时较长), 同步完成并做校验
  • 增量同步:开启 Canal 同步服务, 监听从节点数据库, 再开启主从同步,从节点收到数据后会通过 Canal 服务, 传递至新的 DB 节点。
  • 切换新库:通过 Nginx,切换访问流量至新的服务。
  • 修复切换异常数据:在切换过程中, 如果出现,Canal 未同步,但已切换至新库的请求(比如下单,修改了资金, 但还未同步 ),可以通过定制程序,读取检测异常日志,做自动修复或人工处理。
  • 针对此种情况,最好是在凌晨用户量小的时候,或专门停止外网访问,进行切换,减少异常数据的产生。
  • 数据校验:为保障数据的完全一致,有必要对数据的数量完整性做校验。

1.5 平滑 2N 方案(大数据量)

线上数据库,为了保障其高可用,一般每台主库会配置一台从库,主库负责读写,从库负责读取。下图所示,A,B 是主库,A0 和 B0 是从库。

image.png

1、当需要扩容的时候,我们把A0和B0升级为新的主库节点,如此由2个分库变为4个分库。同时在上层的分片配置,做好映射,规则如下:

把 uid%4=0 和 uid%4=2 的数据分别分配到 A 和 A0 主库中
把 uid%4=1 和 uid%4=3 的数据分配到 B 和 B0 主库中

image.png

2、因为 A 和 A0 库的数据相同,B 和 B0 数据相同,此时无需做数据迁移。只需调整变更一下分片配置即可,通过配置中心更新,不需要重启。

image.png

由于之前 uid%2 的数据是分配在 2 个库里面,扩容之后需要分布到 4 个库中,但由于旧数据仍存在( uid%4=0 的节点,还有一半 uid%4=2 的数据),所以需要对冗余数据做一次清理。

这个清理,并不会影响线上数据的一致性,可以随时随地进行。

3、处理完成之后,为保证数据的高可用,以及将来下一步的扩容需求。

可以为现有的主库再次分配一个从库。

image.png

0

评论区