不停服! 怎么迁移数据

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

本文链接:https://blog.csdn.net/pyycsd/article/details/103041037

前言

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

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

案例

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

数据库: MySQL 表名: order_{0~19}, 其中{0~19}为后缀, 合共20张表. 主键: order_id, 订单ID, 通过雪花算法获得, 可通过ID获取创建时间. 原分表策略: 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的总没错).
  • 数据无价, 谨慎操作.

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java帮帮-微信公众号-技术文章全总结

SQL 查询语句总是先执行 SELECT?你们都错了

很多 SQL 查询都是以 SELECT 开始的。不过,最近我跟别人解释什么是窗口函数,我在网上搜索”是否可以对窗口函数返回的结果进行过滤“这个问题,得出的结论是...

5410
来自专栏百味科研芝士

【文献解读】3分+网络药理学文献套路

目前大火的TCGA,GEO,SEER等数据库更多的关注的是临床基础型研究,对于中医药领域的同胞们似乎不太友好,今天我们就一起学习一篇2019年发表在Biomed...

44310
来自专栏机器学习AI算法工程

Spark + Hadoop,基于WIFI探针的大数据分析系统

本系统以Spark + Hadoop为核心,搭建了基于WIFI探针的大数据分析系统。

15120
来自专栏大数据手稿笔记

你说的 Flink 和搜索引擎有什么关系

搜索引擎的出现大大降低了人们寻找信息的难度,已经深入到生活与工作的方方面面,简单列举几个应用如下:

10310
来自专栏Python疯子

Python的接口的单元测试并自动将结果发至邮件

流程介绍: 1、搭建一个服务 2、编写接口单元测试 3、将单元测试生成报告并自动发送邮箱

6920
来自专栏idba

从Zabbix到Prometheus,同程艺龙数据库监控系统的实践

闫晓宇,同程艺龙数据库技术专家,具有多年互联网行业DB运维经验,在游戏、O2O及电商行业从事过DBA运维工作。2016年加入同程艺龙,目前在团队负责数据库架构设...

18210
来自专栏Java架构沉思录

一种单机支持 JavaWeb 容器万级并发的设想

当前的大部分 Java web 容器基于 Bio 线程模型,例如常见的 Tomcat ,默认 200 线程,即 200 连接。由此带来的问题是,如果想提高并发,...

5120
来自专栏mall学习教程

后端程序员必备:Mysql数据库相关流程图/原理图

mysql主从复制原理是大厂后端的高频面试题,了解mysql主从复制原理非常有必要。

9320
来自专栏IT大咖说

C/S和B/S两种架构区别与优缺点分析

C/S和B/S,是再普通不过的两种软件架构方式,都可以进行同样的业务处理,甚至也可以用相同的方式实现共同的逻辑。既然如此,为何还要区分彼此呢?那我们就来看看二者...

9720
来自专栏机器学习AI算法工程

知识图谱入门 , 知识问答

可以看出,整体进程由基于模板到信息检索到基于知识库的问答。基于信息检索的问答算法是基于关键词匹配+信息抽取、浅层语义分析。基于社区的问答依赖于网民贡献,问答过程...

9920

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励