一次数据迁移分享

数据迁移的初衷

新老数据系统的换代，因为满足业务的需要，我们通常都会对老系统进行重构，为什么要进行重构呢？这个问题肯定是因为老系统不太符合现在业务需求的场景了，说白了就是太low了，为了使公司业务进行可持续性发展，当然要投入人力来进行老项目的重构；一般来说，我们在开发新的业务系统的时候，老的业务系统肯定是在运行的过程中的，当我们新系统到了开发交付上线的时候，其实在一段时间里面我们的系统是并行在使用的，这仅仅是开始。

当我们的新系统运行趋于一个相对稳定的趋势，这时候我们就要考虑如何将老系统的数据同步到新系统上来，逐渐的淘汰老系统，当然这里需要一个过程，我们需要合理的控制每次迁移的节点，尽量做到不去丢失流量数据，也就是系统带来的企业收益。

迁移目标

上游业务系统先进性数据迁移，也就是订单系统、批次、供应商等...系统先进行数据迁移，到我负责的结算系统，会更加上游的订单数据生成结算单据， 老的结算系统数据也需要将拉老数据拉进新系统的db当中0，经过数据迁移演练，如果有问题及时对数据进行回滚，最终完成数据迁移淘汰下线老系统，需要保证数据的准确性。

迁移方案

目前两种方案：1.停机迁移，2.平滑迁移

停机迁移

服务在非业务时间凌晨进行停机，将老系统进行停机，然后运行迁移脚本，将所有老数据迁移至临时迁移表，然后新系统跑脚本将数据跑到新数据库。

平滑迁移

双写方案，不停机的迁移模式，新老系统都进行数据迁移工作的开发。

1. 老系统接入新系统的DB，不在往老库里新增数据，根据新系统的表结构将数据插入到新的表里。

2. 新系统去读老系统DB，将旧的业务数据，根据新系统的业务规则重心生成新的数据，就是无论怎样都要保持新系统跑出来的数据永远是最新的；如果新老数据差距过大，可以通过工具进行数据迁移，当然工具还是比较多的，datax、canal都是db层面的数据迁移工具，业务层面可以集成Spring batch

数据迁移大体框架

结合我们公司的业务场景，我们还是采用停机迁移的方案，首先是因为没有太多人力去两头进行迁移开发，其次是我们的业务在凌晨是不会去跑的，不用去考虑停机带来的业务损失。

• 首先是整体的一个迁移大体框架。

• 其次在每个业务库里，建立mapping映射表，主要生成逻辑，我们这边的是根据老的业务单号通过跑批，一次性将新的业务单号生成并记录在mapping表里，因为我们生产环境的数据量不大通过跑脚本其实还好，如果太大就需要DBA介入。

• 映射表生成后，接下来就是对新生成的业务编码，表里涉及的字段进行在新系统兼容读mapping表，将其他字段通过新系统跑出来，完全匹配新系统的业务逻辑。
• 迁移数据进行删除，来保证迁移数据业务环境运行异常，进行迁移重试。

迁移具体步骤

步骤	具体实施
字段映射	老系统的编码需要根据新系统编码的业务规则，重新生成，并且一一对应起来
非主健业务字段	部分字段需要进行逻辑计算生成、字段差异需要特殊处理
新系统代码修改	生成逻辑加入读映射表方法、批量生成新的单据，并且加入新数据标识字段
数据库份	数据库copy根据迁移日期，将数据库加上日期后缀
验证演练	新生成的数据进行业务验证，出错进行回滚
上线准备	预发环境不同业务分批迁移、分批验证
停机公告	发出迁移停机公告
进行迁移	数据备份、开始迁移、生产验证、新业务代码恢复
后续观察	观察老数据在新系统上的运行情况

迁移结果

历时小半年的时间，终于完成了新老系统的数据迁移，老系统只可读，不做任何增删改操作，新系统依然进行正常业务运行。

总结

数据迁移需要注意以下几点：

1. 首先做好数据备份，做好回退操作，在迁移的过程中肯定避免不了踩坑。
2. 涉及到字段需要计算逻辑赋值，在并发的情况下，需要考虑准备性，关键数据生成需要加锁来老保证数据的一致性。
3. 数据迁移节点制定，需要有序的进行，排好优先级。
4. 如果时间人力充足最好将迁移，实现工具化，可以进行复用。

最后，经过这次的数据迁移经历，还是学习到很多地方，更多的迁移方案制定、项目沟通、问题解决，也算是一次不错的工作经历。