数据迁移案例分析

文章地址: https://blog.piaoruiqing.com/2019/10/27/migrate-data-without-downtime/

前言

数据迁移时, 为了保证数据的一致性, 往往伴随着停服, 此期间无法给用户提供服务或只能提供部分服务. 同时, 为了确保迁移后业务及数据的正确性, 迁移后测试工作也要占用不少时间. 如此造成的损失是比较大的.

接下来, 本文将就如何在不停服的情况下进行数据迁移进行探讨.

案例

订单系统中存在这样一组订单表:

数据库: MySQL

表名: order_{0~19}, 其中{0~19}为后缀, 合共20张表.

主键: order_id, 订单ID, 通过雪花算法获得, 可通过ID获取创建时间.

原分表策略: order_id % 20

伴随着业务量增长, 各分表的数据量已经破千万, 如此下去会产生严重的性能问题, 此时需要将原分表进行迁移.

要求:

有过分库分表经验的读者可能已经发现案例中原分表策略十分不合理, 其缘由不去追究(毕竟换了几波人之后已经没办法找到当年的人吊起来揍了).

分析一下原数据表: 订单数据肯定会伴随着时间和业务量直线上升, 固定的分表数量会导致随数据量增大性能下降. 所以, 数据迁移后, 分表的数量不能再固定, 即使从20改成100个总有一天也会达到瓶颈.

订单数据会伴随时间增长, 而且在超过退款期限后就变成了冷数据, 使用率会降低. 因此, 将订单按照创建时间来进行分表是一个不错的选择. 值得一提的是, order_id是通过雪花算法获得, 可以从order_id中获取创建时间, 可以通过order_id直接获取分片键.

数据迁移的方案从业务层到数据库层各有不同的迁移方案, 我们先列举一些进行比对:

业务层: 在业务层进行硬编码, 数据双写, 以某个时间点进行划分, 新产生的数据同时写入新表, 运行一段时间后将旧数据迁移至新表. 成本极高, 与业务耦合严重, 不考虑.
连接层: 是方案1的进阶版, 在连接层拦截SQL进行双写, 与业务解耦, 但与1有着同样的一个问题: 周期较长, 要确保旧数据不会产生变更才能进行迁移.
触发器: 通过触发器将新产生的数据同步到新表, 本质上与2差不多.
数据库日志: 从某一时间点T备份数据库, 将备份库的数据迁移至新表, 从时间点T读取日志, 恢复到新表, 并持续写入. 待两份数据保持同步后, 上线新代码.
伪装从库: 相对于方案4的优势是不需要直接去读取日志, 解决了数据库在云上不方便直接读取日志的问题.