一、为什么需要扩容
假设目前有3个库, 基于UID进去取模分片,数据可以均衡的分配到3个数据库中,具体规划如下:
如果要增加新的节点, 该如何扩容?需要对数据库进行水平扩容, 新库加入之后,数据由原来的3个库就拆分至4个库里面。
此时由于分片规则发生了变化(uid%3 变为uid%4),导致大部分的数据,无法命中原有的数据,需要重新进行分配,要做大量的数据迁移处理。
比如之前uid如果是uid7取模1, 是分配在B库上,新加入D库后, uid7取模4,是分配在D库上;
新增一个节点, 大概会有90%的数据需要迁移, 这样会面临大量的数据压力,并且对服务造成极大的不稳定性。
二、停机方案
- 发布公告
- 停止服务
- 离线数据迁移(拆分,重新分配数据)
- 数据校验
- 更改配置
- 恢复服务
- 回滚预案
问题:
停服之后, 能够保证迁移工作的正常进行, 但是服务停止,伤害用户体验, 并造成了时间压力, 必须在指定的时间内完成迁移。
三、停写方案
- 支持读写分离
- 升级公告
- 中断写操作,隔离写数据源(或拦截返回统一提示)
- 数据同步处理
- 数据校验
- 更改配置
- 恢复写操作
- 数据清理
- 回滚预案
问题:
虽然比停机方案有所改进,能够提供读取服务, 但是不能保障核心业务数据的正常写入,同样会伤害用户体验, 也会存在时间压力。
四、日志方案
核心是通过日志进行数据库的同步迁移, 主要操作步骤如下:
-
数据迁移之前, 业务应用访问旧的数据库节点。
-
日志记录
在升级之前, 记录“对旧数据库上的数据修改”的日志(这里修改包括增、删、改),这个日志不需要记录详细的数据信息,主要记录:
(1)修改的库;
(2)修改的表;
(3)修改的唯一主键;
(4)修改操作类型。
日志记录不用关注新增了哪些信息,修改的数据格式,只需要记录以上数据信息,这样日志格式是固定的, 这样能保证方案的通用性。
服务升级日志记录功能风险较小:
写和修改接口是少数, 改动点少;
升级只是增加了一些日志,采用异步方式实现, 对业务功能没有太多影响。
-
数据迁移:
研发定制数据迁移工具, 作用是把旧库中的数据迁移至新库中。
整个过程仍然采用旧库进行对外服务。
数据同步工具实现复杂度不高。
只对旧库进行读取操作, 如果同步出现问题, 都可以对新库进行回滚操作。
可以限速或分批迁移执行, 不会有时间压力。
数据迁移完成之后, 并不能切换至新库提供服务。
因为旧库依然对线上提供服务, 库中的数据随时会发生变化, 但这些变化的数据并没有同步到新库中, 旧库和新库数据不一致, 所以不能直接进行切换, 需要将数据同步完整。
-
日志增量迁移
研发一个日志迁移工具,把上面迁移数据过程中的差异数据追平,处理步骤:
读取log日志,获取具体是哪个库、表和主键发生了变化修改;
把旧库中的主键记录读取出来
根据主键ID,把新库中的记录替换掉
这样可以最大程度的保障数据的一致性。风险分析:
整个过程, 仍然是旧库对线上提供服务;
日志迁移工具实现的复杂度较低;
任何时间发现问题, 可以重新再来,有充分的容错空间;
可以限速重放处理日志, 处理过程不会因为对线上影响造成时间压力。
但是, 日志增量同步完成之后, 还不能切换到新的数据库。
因为日志增量同步过程中,旧库中可能有数据发生变化, 导致数据不一致,所以需要进一步读取日志, 追平数据记录; 日志增量同步过程随时可能会产生新的数据, 新库与旧库的数据追平也会是一个无限逼近的过程。
-
数据校验
准备好数据校验工具,将旧库和新库中的数据进行比对,直到数据完全一致。
-
切换新库
数据比对完成之后, 将流量转移切换至新库, 至此新库提供服务, 完成迁移。
但是在极限情况下, 即便通过上面的数据校验处理, 也有可能出现99.99%数据一致, 不能保障完全一致,这个时候可以在旧库做一个readonly只读功能, 或者将流量屏蔽降级,等待日志增量同步工具完全追平后, 再进行新库的切换。
至此,完成日志方案的迁移扩容处理, 整个过程能够持续对线上提供服务, 只会短暂的影响服务的可用性。
问题:
这种方案的弊端,是操作繁琐,需要适配多个同步处理工具,成本较高, 需要制定个性化业务的同步处理, 不具备普遍性,耗费的时间周期也较长。
五、双写方案(中小型数据)
双写方案可通过canal或mq做实现。
-
增加新库,按照现有节点, 增加对应的数量。
-
数据迁移:避免增量影响, 先断开主从,再导入(耗时较长), 同步完成并做校验
-
增量同步:开启Canal同步服务, 监听从节点数据库, 再开启主从同步,从节点收到数据后会通过Canal服务, 传递至新的DB节点。
-
切换新库:通过Nginx,切换访问流量至新的服务。
-
修复切换异常数据:在切换过程中, 如果出现,Canal未同步,但已切换至新库的请求(比如下单,修改了资金, 但还未同步 ), 可以通过定制程序, 读取检测异常日志,做自动修复或人工处理。
针对此种情况, 最好是在凌晨用户量小的时候, 或专门停止外网访问,进行切换,减少异常数据的产生。
-
数据校验:为保障数据的完全一致, 有必要的数据的数量完整性做校验。
问题:
该方案需要有双倍的应用服务器和数据库服务器, 耗费较多的硬件资源成本,且增加维护部署工作量;数据库全量同步耗费时间周期较长,且需要增量同步组件来保障数据一致性。
六、平滑2N方案(大数据量)
-
线上数据库,为了保障其高可用,一般每台主库会配置一台从库,主库负责读写,从库负责读取。下图所示,A,B是主库,A0和B0是从库。
-
当需要扩容的时候,我们把A0和B0升级为新的主库节点,如此由2个分库变为4个分库。同时在上层的分片配置,做好映射,规则如下:
uid%4=0和uid%4=2的分别指向A和A0,之前指向uid%2=0的数据,重新调整为uid%4=0和uid%4=2;
uid%4=1和uid%4=3的指向B和B0,之前指向uid%2=1的数据,重新调整为uid%4=1和uid%4=3。
-
因为A和A0库的数据相同,B和B0数据相同,此时无需做数据迁移。只需调整变更一下分片配置即可,通过配置中心更新,不需要重启。
由于之前uid%2的数据是分配在2个库里面,扩容之后需要分布到4个库中,但由于旧数据仍存在(uid%4=0的节点,还有一半uid%4=2的数据),所以需要对冗余数据做一次清理。
这个清理,并不会影响线上数据的一致性,可以随时随地进行。
-
处理完成之,为保证数据的高可用,以及将来下一步的扩容需求。
可以为现有的主库再次分配一个从库。
本文由mirson创作分享,如需进一步交流,请加QQ群:19310171或访问www.softart.cn