数据迁移怎么做？ _数据迁移

随着企业数字化的深入，系统上云或者国产化改造的需求也是越来越多，数据迁移作为其中的重点中的重点，绝对是不可绕开的一个关键环节。可能有人会觉得数据迁移不是很简单吗，用binlog把数据同步到新库不就完了吗？这就把问题想简单了，事实上数据迁移架构可能会非常复杂，而且每个企业可能都面临着不同的现状与历史情况。比如不是所有的系统数据库都是MySQL，像金融等大型企业的系统早期大量使用了Oracle或其它的一些商业数据库，甚至在某些限制的情况下DBA团队都不提供7*24小时的主备同步的功能。这时你的架构应该怎么设计？

文章插图
一般来说系统按服务对象可以分为ToC、ToB、ToG，对于后两类系统或者规模较小的ToC类系统，通常可以有停机发布窗口，有停机窗口的系统数据迁移比无停机窗口7*24小时提供在线服务的系统相对来说会简单不少
对于小型系统来说，系统的割接可能比较简单，通常会在新系统中验证通过后观察一段时间，确认不存在回切风险后逐步下线旧系统即可。而对于大型系统来说，系统割接的时间可能持续几个月甚至数年的时间，就像在飞行的飞机上换发动机一样。对于高并发系统，数据的迁移除了数据库的迁移外还需要考虑缓存的数据迁移或预热以防止新系统在切入流量后发生缓存击穿而雪崩。下面是一些常用的策略和对限制性条件下的思考：
最简单的数据迁移策略先来看一下最简单的数据迁移策略：即可停机的一次性迁移。也就是说在停机发布窗口内，完成数据迁移并完成新环境的功能验证测试，等恢复后用户访问到的系统已经更新为新系统。这种方式的优点是方案简单，缺点是当正常提供服务时间发现新环境存在重大问题时，由于新环境的数据库通常已经写入了新数据，已经没办法切回到旧环境的旧系统，所以这种策略适用于小规模系统。
具体的做法是在停机维护开始后先在旧数据库中执行mysqldump，再在新数据库中导入dump文件，这种方式甚至都不要求新旧环境之间的网络互通。在dump文件导入成功后，先进行数据验证，通过后数据迁移工作即基本完成。再对新环境的应用程序进行功能验证测试，通过后切换流量入口让新环境接替旧环境对外提供服务。见下图：

文章插图
可回切的迁移策略再来看一下稍微复杂一点的数据迁移策略：可回切的迁移策略。为了降低迁移的风险，企业通常会考虑在迁移完成并开始对外提供服务出现问题时进行回切。为了满足回切的需求，我们通常会让新旧两套数据库之间进行数据同步，新环境数据库为主库，旧环境数据库为从库，在回切时进行手工的主从倒换。这种方式也要求新旧环境间的网络是互通的。

文章插图

如上图，刚开始，旧环境数据库作为主库，新环境数据库作为从库。为了进一步减少数据迁移的时间，可先把新环境的应用程序部署等各类工作提前做好，先不切入流量入口即可。

文章插图
如上图，在停机发布窗口到来时，先停止旧环境流量，确认主从数据库数据同步完成后，手工执行主从倒换将旧环境数据库转换为从库，新环境数据库转换为主库。在对外提供服务后，由于写入新数据库的数据也会同步到旧数据库，只要新旧库之间的数据一致，旧服务就具备了回切的条件。
当发现新环境服务存在严重问题需要回切时，先停止新环境流量，确认数据同步完成后手工执行主从倒换并将流量入口切回旧环境。由于主从间的同步可以在数据迁移前就持续进行，真正迁移时只需要确认从库的数据追上了主库的数据后进行手工主从倒换，所以在这种方式也适用于很短停机窗口的系统。
双写的迁移策略接下来我们来看一下更为复杂的异构数据库迁移策略：双写策略。前面介绍的两种策略都适用于同构数据库的数据迁移，但是对于异构数据库之间的数据迁移，我们应该如何设计呢？毕竟国产化改造多数情况是从一些商业数据库往国产或开源的数据库上进行迁移居多。
有一些商业的异构数据迁移工具号称可以支持7*24小时的异构数据库同步，但由于不同商业数据库拥有各自丰富的特性，很难覆盖所有方面。因此，我认为可以使用这类商业工具来进行存量数据的辅助迁移和验证，但对于实时产生的增量数据，主要还是依靠应用程序的双写机制来处理。