数据迁移案例分析git
文章地址: blog.piaoruiqing.com/blog/2019/1…github
数据迁移时, 为了保证数据的一致性, 每每伴随着停服, 此期间没法给用户提供服务或只能提供部分服务. 同时, 为了确保迁移后业务及数据的正确性, 迁移后测试工做也要占用很多时间. 如此形成的损失是比较大的.算法
接下来, 本文将就如何在不停服的状况下进行数据迁移进行探讨.数据库
订单系统中存在这样一组订单表:post
数据库: MySQL性能
表名: order_{0~19}, 其中{0~19}为后缀, 合共20张表.测试
主键: order_id, 订单ID, 经过雪花算法得到, 可经过ID获取建立时间.ui
原分表策略: order_id % 20编码
伴随着业务量增加, 各分表的数据量已经破千万, 如此下去会产生严重的性能问题, 此时须要将原分表进行迁移.设计
要求:
有过度库分表经验的读者可能已经发现案例中原分表策略十分不合理, 其原因不去追究(毕竟换了几波人以后已经没办法找到当年的人吊起来揍了).
分析一下原数据表: 订单数据确定会伴随着时间和业务量直线上升, 固定的分表数量会致使随数据量增大性能降低. 因此, 数据迁移后, 分表的数量不能再固定, 即便从20改为100个总有一天也会达到瓶颈.
订单数据会伴随时间增加, 并且在超过退款期限后就变成了冷数据, 使用率会下降. 所以, 将订单按照建立时间来进行分表是一个不错的选择. 值得一提的是, order_id是经过雪花算法得到, 能够从order_id中获取建立时间, 能够经过order_id直接获取分片键.
数据迁移的方案从业务层到数据库层各有不一样的迁移方案, 咱们先列举一些进行比对:
业务层: 在业务层进行硬编码, 数据双写, 以某个时间点进行划分, 新产生的数据同时写入新表, 运行一段时间后将旧数据迁移至新表. 成本极高, 与业务耦合严重, 不考虑.
链接层: 是方案1的进阶版, 在链接层拦截SQL进行双写, 与业务解耦, 但与1有着一样的一个问题: 周期较长, 要确保旧数据不会产生变动才能进行迁移.
触发器: 经过触发器将新产生的数据同步到新表, 本质上与2差很少.
数据库日志: 从某一时间点T备份数据库, 将备份库的数据迁移至新表, 从时间点T读取日志, 恢复到新表, 并持续写入. 待两份数据保持同步后, 上线新代码.
假装从库: 相对于方案4的优点是不须要直接去读取日志, 解决了数据库在云上不方便直接读取日志的问题.
相比较之下, 方案4和5都是可选的, 因数据库在云上, 直接读取日志不方便, 且方案5有成熟的开源中间件**canal**可用, 故笔者选择了方案5.
Canal文档地址: github.com/alibaba/can…
新代码上线后, 谁也不能确保百分百没问题. 若迁移失败, 必需要进行回滚. 因此, 须要保证原数据和新数据的同步.
因此, 在前一小节方案5的基础上, 切流量到新集群后, 咱们中止数据同步, 从切流量时刻开始同步新表数据到旧表, 方案也是假装从库. 如此就能保证新旧表的数据同步, 若是上线后发生了异常, 将流量切回旧集群便可.
flush logs
: 生成新的binlog, 恢复数据将从这里开始.flush logs
生成新的binlog, 新表向旧表同步数据将从这里开始.上线后应及时进行测试, 一旦发现严重的异常就当即将流量切回旧集群.
flash logs
要先于备份源数据表, 即便中间有些许时间间隔也不会影响数据的最终一致 (听binlog的总没错).若是这篇文章对您有帮助,请点个赞吧 ( ̄▽ ̄)"
欢迎关注公众号(代码如诗):