分享一次海量数据平滑迁移实战
![分享一次海量数据平滑迁移实战](https://static001.geekbang.org/infoq/11/1110568b27af43eb6f354b76cf8dbf3c.jpeg)
背景
采购系统(BIP)在经历多年演进后,系统整体复杂度和数据量俨然已经极具规模,本文着重讨论海量数据的治理
存储现状:工程端实时订单库采用 MySQL 5.5 集群,其中主库配置为 32C/48G/6000G,无法归档的订单热数据占磁盘空间 85%(5.1T)
痛点:6T 磁盘已经单容器最大,无法继续扩容,剩余磁盘余量过小,难适应未来发展
目标
降低磁盘容量,优化数据模型,提升系统稳定性
调研
首先,既然是要解决存储容量的问题,就要对详细的容量情况有个更加清楚的了解。总结下当前存储容量问题,最大的表是订单操作日志表 lifecycle 共 1.3T,大于 500G 的表 2 张共 1.5T;100G~500G 的表 10 张共 2.6T。以下是优化前库里大表(大于 100G)的详细空间占用情况:
其次,确认当前最高效的优化思路是将 lifecycle 表迁移到其他库,原因有二:1.lifecycle 表的含义是操作日志,在业务上不算订单域内最核心的模型,风险可控;2.占用空间大,单表 46 亿行数据,空间占用 1.3T,一张表占了磁盘空间的 22%,优化的 ROI 高
最后,想说明下,为什么没有直接将整个库,从传统 MySQL 切换到 JED,原因也有二:1.JED 和 MySQL 的查询语法还是有一定差异,直接切换,成本和风险极高;2.切换存储中间件,获取分布式架构下更大的存储空间并不是银弹,理智告诉我们要结合系统现状,不可盲目下定论
挑战
保障海量数据(存量 46 亿行,增量 600w+行/天,TPS 峰值:500+,QPS 峰值:200+)迁移期间读、写稳定和准确。需要补充一下:lifecycle 虽然不算订单最核心业务模型,但依旧是辅助业务决策的关键数据,也非常重要
例子:
![](https://static001.geekbang.org/infoq/d6/d6d3eb21ac1f1f3c35509a06adfc1abd.png)
方案
整体方案
数据同步 -> 双读 -> 双写 -> 离线验证 -> 数据清理
![](https://static001.geekbang.org/infoq/1e/1ebb54556e65e4efd3785597deda7488.png)
详细设计
•数据同步,通过 DRC 实现,历史全量+增量,其中有以下几点使用心得:
◦同步速度问题,本次是使用传统 MySQL5.5 -> JED 底层 MySQL 8.0 单表同步,效率大概是 4M/S,一共花了 3 天半左右
◦数据同步过程中不要操作暂停,否则任务重启后,会重新同步历史数据,导致数据同步周期变长。详情参考: 关于全量任务暂停重启之后数据同步慢的原因
◦字段兼容问题,老库历史时间字段类型是 datetime,新库需要改为 datetime(3),这种数据同步是可以兼容的(下文会讲为什么要优化时间字段精度)
◦数据验证问题,当时在历史数据全量同步完毕后开启了 DRC 数据验证,但是许久未执行完成,收到 DRC 运维告知出现大量报错,最终结论是暂时不支持这两个版本的数据比对(5.5->8.0),这也是为什么整体架构上采用 BDP 抽数比对数据的主要原因
•数据验证,业务程序完成双写、双读改造
◦双写
![](https://static001.geekbang.org/infoq/68/68b02b7100d3bfd541f4a4a0a2d78418.png)
▪为什么采用双写?答:控制风险。1.团队内还没有应用直接写入多分片 JED 的先例,而且新、老库的底层 MySQL 版本也差异比较大(5.5 vs 8.0),当时通过分批次灰度上线完成逐步切量验证;2.方便进行数据验证,lifecycle 是业务操作日志,基本涵盖了所有的写入场景,其中因为历史问题,不乏一部分逻辑和订单更新在同一事务中,现在迁移到新库,本地事务会存在不生效的场景
▪具体改造方案:
▪新增【验证开关】,开启后新/老库双写,另外需要要引入 vitess 驱动,目前只支持 JDK8 及以上
▪新增【上线开关】,开启后只写新库,此开关是在验证逻辑无问题后,最终切换的开关,代表迁移完成
▪注意,开关改造完成上线后,“全量+增量 DRC 任务”在验证期间是一直启用的,也就是说验证期间,增量数据会写两份到新库
▪一部分是实际的生产数据,一部分是待验证的测试数据。那么就带来另一个问题,如何识别和区分这两部分数据,我们采用的方案是:JED 建表指定趋势自增的最小 id(200 亿)+【验证开关】开启的时间戳进行区分
▪如下图,其中 A 和 A'都是【验证开关】切换后的增量数据,由于老库的 id 已经自增写到了 70 亿,并且 DRC 同步任务也是指定 id 写入,所以建表时指定新增数据 id 是 200 亿(详情参考: 数据库自增ID列设置 ),和老数据之间存在一定 gap 方便识别。BDP 脚本数据比对的也是:老库.A 和新库.A'(这里默认 DRC 增量同步的数据是准确的)
▪清除测试数据,真正完成【上线开关】切换,需要提前清除测试数据,只需指定 id>200 亿的物理删除即可。注意:针对多分片的 JED 物理删除 delete 语句,我们程序上如果为了防止大事务,而采用“for 循环+limit n”的方式执行,实际的每次 SQL 语句执行结果是多个分片的 n 的聚合,而不是 n,如果程序上对结果有判断逻辑,需要额外注意
![](https://static001.geekbang.org/infoq/b3/b3511db854e317323e2fc731f64dc2e1.png)
◦双读
![](https://static001.geekbang.org/infoq/ee/ee2509f57d04515618608fda71e9941c.png)
▪整体逻辑基本复用写入期间已有开关,其中针对新库当中 DRC 实时同步的数据(上图:新库.A)会根据开关开启时间进行过滤
▪其中,在验证期间,新、老库都会根据采购单号进行查询并实际返回老库的查询结果,其中还会进行结果比对,出现数据不一致会输出异常日志关键字
▪另外,因为 lifecycle 操作日志数据是有先后顺序的,老库的处理方式是根据自增 id 进行倒排,到了新库以后,由于采用的是 JED 分片(分布式存储的磁盘空间更大),考虑到开发成本,数据 id 采用的是趋势递增的自增主键(详情参考: Vitess全局唯一ID生成的实现方案 ),这时多集群并行写入无法继续使用基于 id 倒排的方式返回结果(后写入的数据可能 id 较小,可以参考 sequece 发号器的 ID 生成),所以将原始的数据写入时间戳从 datetime 提高精度到 datetime(3),通过数据写入时间进行倒排,这里也解释了上文,新库 DRC 数据同步为什么要考虑字段兼容的问题
▪补充 1:这里基于时间倒排在业务上是准确的,因为 lifecycle 数据是根据订单号进行分片的,所以同一订单一定落在单分片上,也就是说不存在不同分片时钟偏移的问题,单订单的操作日志的时间序列一定是按照写入顺序逐渐增加的
▪补充 2:新库字段类型变更(datetime->datetime(3)),32 分片,共 46 亿行数据,执行了大概 1 小时,期间主从延迟最高 30 分钟,容器负载正常
▪补充 3:应用的关键字告警配置,日志文件仅支持以 error.log、err.log、exception.log 结尾,并开启历史日志的路径
▪最后,双读期间共通过业务的实际查询流量发现数据不一致问题 2 个+,在并未影响到业务使用的前提下及时发现了系统异常
◦离线验证
▪lifecycle 归根结底还是写多读少的业务场景,为了防止出现上文数据比对验证的遗漏,我们会采用 BDP 离线任务会分别开启增量数据+历史全量数据验证。通过对新、老库的全量数据字段相互 sql inner join 的方式完成比对,其中会忽略 id 和写入时间,因为新库的 id 不是单调递增、时间精确到了毫秒。期间共发现有效数据问题 3 个+,均是因为本地事务回滚导致的数据不一致的场景
•收尾工作
◦完成【上线开关】切换,只读、写新库,完成整体平滑迁移。在无 QA 参与前提下,验证期间未出现过数据丢失、重复、错误等异常
◦切换完成后,老库老表和 DRC 同步任务依旧保留了一周的时间,防止出现场景遗漏,产生数据丢失
◦46 亿行大表清理,采用 drop+create 的方式实现效率、稳定性更高,在业务低峰期完成脚本执行,大概花费 10 秒的时间,容器负载、内存等指标正常。但是当时碰上了 DBA 的备份任务,导致有一个从库主从延迟升高,这个后续需要注意
成果
•采购系统订单实时库磁盘容量减少 1.3T,占用比率从 85%下降到 63%,结合已有数据归档程序,可以支撑未来三年的业务发展
•由于历史原因,先前 lifecycle 有 21 亿冷数据存储在另外一个大规格 JED 集群,也一并完成读、写流量摘除,预计 2024Q1 完成下线,届时会节省 800C+、内存 2T+、磁盘 35T+的容器资源
版权声明: 本文为 InfoQ 作者【京东零售技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/500816c7e30cb7aa2f35ac372】。文章转载请联系作者。
评论