MySQL 数据库平滑扩容方案剖析 - 第三篇

 由于讲述内容较多，故拆分了四个小篇

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 只读功能，等待日志增量同步工具完全追平后， 再进行新库的切换。

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

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