由于讲述内容较多,故拆分了四个小篇
MySQL 数据库平滑扩容方案剖析 - 第一篇_YZF_Kevin的博客-CSDN博客
MySQL 数据库平滑扩容方案剖析 - 第二篇_YZF_Kevin的博客-CSDN博客
MySQL 数据库平滑扩容方案剖析 - 第三篇_YZF_Kevin的博客-CSDN博客_mysql 数据扩容
MySQL 数据库平滑扩容方案剖析 - 第四篇_YZF_Kevin的博客-CSDN博客
数据迁移之前, 业务应用访问旧的数据库节点,如下图:
方案三(记录日志切换方案 )
核心是通过日志进行数据库的迁移和同步, 主要操作步骤如下:
1. 日志记录
在升级之前,需要记录 “对旧数据库上的数据修改” 的日志(这里修改包括增、删、改),这个日志不需要记录详细的数据信息,只记录:
(1)修改的库名;
(2)修改的表名;
(3)修改的唯一主键;
(4)修改的方式;
日志记录不用关注新增了哪些信息,也不用关注修改数据的具体内容,只需要记录以上简要数据信息,这样日志格式是固定的, 能保证方案的通用性。
服务日志记录功能风险较小:
写和修改接口是少数, 改动点少;
只是增加了一些日志,且采用异步方式实现, 对业务功能没有太多影响。
2. 迁移数据库的数据
研发数据迁移工具, 目的是把旧库中的数据迁移至新库中。
整个DB迁移过程只有旧库对外提供服务。
数据同步工具实现复杂度不高。
迁移工具只对旧库进行读取操作, 如果同步出现问题, 可以对新库进行回滚操作。
可以限速或分批迁移执行, 不会有时间压力。
数据迁移完成之后, 并不会立即切换至新库提供服务。
因为旧库一直对线上提供服务, 库中的数据时刻都在发生变化, 但这些变化的数据并没有全部同步到新库中, 旧库和新库数据始终不一致, 所以还不能直接进行切换, 需要将数据同步完整。
3. 迁移日志增量
研发一个日志迁移工具,把上面迁移数据过程中的差异数据追平,处理步骤:
读取 log 日志,获取具体是哪个库、表和主键发生了变化修改;
把旧库中的主键记录读取出来
根据主键 ID,把新库中的记录替换掉
这样可以最大程度的保障数据的一致性。风险分析:
整个过程, 仍然是旧库对线上提供服务;
日志迁移工具实现的复杂度较低;
任何时间发现问题, 可以重新再来,有充分的容错空间;
可以限速重放处理日志, 处理过程不会因为对线上影响造成时间压力。
但是, 日志增量同步完成之后, 还不能切换到新的数据库。
因为日志增量同步过程中,旧库中可能有数据发生变化, 导致数据不一致,所以需要进一步读取日志, 追平数据记录;日志增量同步过程随时可能会产生新的数据, 新库与旧库的数据追平也会是一个无限逼近的过程。
4. 数据校验
准备好数据校验工具,将旧库和新库中的数据进行比对,直到数据完全一致。
5. 切换新库
数据比对完成之后, 将流量转移切换至新库, 至此新库提供服务, 完成迁移。
方案三总结
由于旧DB一直在进行CURD,一直有日志产生,即便通过上面的数据校验处理, 但不能保障完全一致,这个时候可以在旧库做一个 readonly 只读功能,等待日志增量同步工具完全追平后, 再进行新库的切换。
至此,完成日志方案的迁移扩容处理, 整个过程能够持续对线上提供服务, 只会短暂的影响服务的可用性。
这种方案的弊端,是操作繁琐,需要适配多个同步处理工具,成本较高, 需要制定个性化业务的同步处理, 不具备普遍性,耗费的时间周期也较长。