不停服! 怎么迁移数据

数据迁移案例分析git

文章地址: blog.piaoruiqing.com/blog/2019/1…github

前言

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

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

案例

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

数据库: MySQL性能

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

主键: order_id, 订单ID, 经过雪花算法得到, 可经过ID获取建立时间.ui

原分表策略: order_id % 20编码

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

要求:

  1. 将原20张分表数据迁移至新表
  2. 迁移全过程当中不可停机, 须对外提供完整的服务.
  3. 提供完备的回退方案, 迁移过程当中产生的数据不可丢, 不能人为修数据.

原分表策略

分析

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

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

订单数据会伴随时间增加, 并且在超过退款期限后就变成了冷数据, 使用率会下降. 所以, 将订单按照建立时间来进行分表是一个不错的选择. 值得一提的是, order_id是经过雪花算法得到, 能够从order_id中获取建立时间, 能够经过order_id直接获取分片键.

新分表策略

迁移方案分析

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

  1. 业务层: 在业务层进行硬编码, 数据双写, 以某个时间点进行划分, 新产生的数据同时写入新表, 运行一段时间后将旧数据迁移至新表. 成本极高, 与业务耦合严重, 不考虑.

  2. 链接层: 是方案1的进阶版, 在链接层拦截SQL进行双写, 与业务解耦, 但与1有着一样的一个问题: 周期较长, 要确保旧数据不会产生变动才能进行迁移.

  3. 触发器: 经过触发器将新产生的数据同步到新表, 本质上与2差很少.

  4. 数据库日志: 从某一时间点T备份数据库, 将备份库的数据迁移至新表, 从时间点T读取日志, 恢复到新表, 并持续写入. 待两份数据保持同步后, 上线新代码.

  5. 假装从库: 相对于方案4的优点是不须要直接去读取日志, 解决了数据库在云上不方便直接读取日志的问题.

相比较之下, 方案4和5都是可选的, 因数据库在云上, 直接读取日志不方便, 且方案5有成熟的开源中间件**canal**可用, 故笔者选择了方案5.

Canal文档地址: github.com/alibaba/can…

数据迁移

回退方案分析

新代码上线后, 谁也不能确保百分百没问题. 若迁移失败, 必需要进行回滚. 因此, 须要保证原数据和新数据的同步.

因此, 在前一小节方案5的基础上, 切流量到新集群后, 咱们中止数据同步, 从切流量时刻开始同步新表数据到旧表, 方案也是假装从库. 如此就能保证新旧表的数据同步, 若是上线后发生了异常, 将流量切回旧集群便可.

总体方案设计

备份源数据

  1. 执行flush logs: 生成新的binlog, 恢复数据将从这里开始.
  2. 备份数据表(order_{0~19}): 将源(旧)数据表从主库A复制到备份库B

备份源数据

恢复并同步数据

  1. 在主库A建立足够的新表, order新表按照月进行分表.
  2. 写脚本读取备份库B中的order表, 写入主库A的order新表.
  3. 经过canal开始同步旧表数据到新表, 命名为[同步过程-a].

同步数据

上线

  1. 编译新代码并弹一个新的集群, 确认彻底启动完成.
  2. 执行flush logs生成新的binlog, 新表向旧表同步数据将从这里开始.
  3. 流量切到新集群.
  4. 中止[同步过程-a].
  5. 开始重新表向旧表同步数据.

回退

上线后应及时进行测试, 一旦发现严重的异常就当即将流量切回旧集群.

结语

  • flash logs要先于备份源数据表, 即便中间有些许时间间隔也不会影响数据的最终一致 (听binlog的总没错).
  • 数据无价, 谨慎操做.

若是这篇文章对您有帮助,请点个赞吧 ( ̄▽ ̄)"

推荐阅读

欢迎关注公众号(代码如诗):

[版权声明]
本文发布于 朴瑞卿的博客, 容许非商业用途转载, 但转载必须保留原做者 朴瑞卿 及连接: blog.piaoruiqing.com. 若有受权方面的协商或合做, 请联系邮箱: piaoruiqing@gmail.com.
相关文章
相关标签/搜索