本文梳理总结了数据库如何迁移？数据库数据迁移方案步骤的工作要点和分析思路，为同行做好恰当的规划及实施提供借鉴。
1.数据迁移概述
数据迁移，是一个十分复杂的过程，不单单是将数据从一个地方转移到另一个地方。这里应该考虑业务定义、架构变更、应用改造、数据安全等诸多方面的问题。在具体迁移工作中，一定要结合企业的各个方面，做好合理的规划与实施，不然很可能会致使迁移结果无法达到预期，耗费人力财力。在即将开始迁移之前，有几项任务是一定要提前考虑的。
2.迁移方案
1).方案调研
在迁移前，尤为重要的就是确定迁移方案。针对数据迁移，能够有很多类迁移方式，包括数据库、存储、虚拟机、卷、主机、网络、应用等等。这里应该根据我们自己的要求，圈定采用哪种迁移方式；然后就是明确详细的迁移方案，如果涉及到外部商业应用方案，还需要进行相应的POC测试；再次就是细化方案，确定具体迁移步骤（含迁移、回退、验证）等。下面描述下比较常见的这几类迁移方案。
数据库方案
假如是同种数据库，可以采用备份、还原方式；异构的话，可以采取导入、导出方式。现在还有种比较通用方案，是消费源端的日志，将其转化成标准消息，然后对端消费应用。这种方式通用性较好，可实现同构、异构、跨平台的迁移；增量部分，通过源端的日志实时捕获，也可以实现。当然对于全量数据来说，还是建议采取异步方式，集中处理，这样效率比较高。
虚拟机方案
VMware、Hyper-V等虚拟化产品也都提供在线替代迁移功能。虚拟机的在线迁移功能可以实现无中断的迁移，但是并不是所有场景都可以使用这种方案进行迁移。因此虚拟机迁移需要首先核对是否场景限制上能够满足。
操作系统方案
对于文件系统场景，由于各个厂商的元数据结构不一样，一般都需要通过文件迁移工具从文件层进行拷贝和复制，保留文件的属性和权限，而不能从底层块数据层进行迁移。所以文件系统相对简单，常见的诸如Linux下Rsync工具，就是一个远程数据同步工具，可通过LAN或WAN快速同步多台主机间的文件。
卷方案
在大多数操作系统上都提供卷管理软件，将SAN裸设备进行行聚合或者拆分后提供给上层应用使用，因此绝大多数应用数据都通过卷管理软件进行管理，所以卷管理软件自带的镜像和迁移功能常常成为在线数据迁移方案的一种选择。常见的如Linux下的LVM、Oracle自带的ASM等，通过这些不同的卷管理软件实现数据在线迁移到新的目标存储。
网络方案
虚拟化网关产品通过自带的存储虚拟化功能可以实现迁移功能。比如笔者之前使用过的EMCVplex系列等。这种方式首先是通过虚拟化网产品将源存储接管，让源存储和业务主机之间的所有数据都通过网关产品进行传递，再通过网关产品将数据完整的从块级别镜像复制到目标新存储。这种方案具有很强的普适性，可以在大部分的场景下使用。但是由于镜像复制只是实现了数据复制到目标新存储，而原来的业务主机上的多路径，卷管理，集群和数据库等软件都是和源存储进行绑定的，因此在数据同步到目标存储的后，还需要将业务和源存储的绑定关系替换为目标存储，这个过程是整个数据迁移过程中最复杂的部分。
存储方案
存储设备本身也具备一些数据迁移功能，如LUN拷贝和远程复制。LUN拷贝可以把目标新存储作为一个服务器，首先将源存储映射到目标新存储，再将目标新存储上的所有数据读出来写到目标存储上。远程复制可以从数据块层面将数据从一台存储同步到远端的另一套存储，但一般要求源存储和目标存储都是来自一家的同平台产品。此功能经常被用于存储的跨地域数据迁移。
应用方案
应用方案，可以说是万能的方案，客户可根据自身情况定制迁移方案。其往往是最灵活的，当然也是复杂度相对较高的一种。常用的方法开发一个全量的迁移工具，进行数据迁移；增量部分，采用读取源端日志的方式补齐；此外配合必要的数据对比工具完成。在新旧系统数据基本同步后，断掉旧系统，切换到新系统。这种方式可以实现比较平滑的迁移，全程可控；但问题在于如果出现问题，还需考虑回退流程，最好能实现双向同步，但这种复杂度又增大不少。
还有一种就是所谓的“双写法”，先利用数据同步工具完成初始的数据同步，对于增量部分采用应用双写的方式完成，这里只要保证必要的数据幂等性即可。
2).方案测试应用
在明确了迁移方案后，需进行完备的方案测试；如涉及到自研部分，需尽早启动开发工作。如要采购外部产品，也需要在此阶段进行测试。这个阶段的测试，主要目的是验证方案可行性，特别是数据安全方面。对可能出现的风险，要充分评估，并将其纳入到后续方案细节中。此外，也需要在此阶段收集必要的性能数据，为后续评估新系统配置、停机窗口等，做必要的准备。如有多种方案均可行，也可以在测试阶段具体比较其差异，找出最为适合的一种。
数据迁移包括全量和增量数据迁移。具体方法可参照之前说明。这里重点谈下迁移之后的数据校验问题，在完成新数据平台的搭建后，一般会和原有的数据平台并行运行一段时间，一方面是为了和原有平台进行业务和数据的比对，确保业务的正确性和连续性；另一方面，应用改造迁移是一个循序渐进的过程，在所有应用迁移完成前，原有数据平台还是要承担正常的业务访问。一般的做法是通过类似灰度发布的过程，开始的时候同时往两个平台写入数据，但只有原有数据平台对外提供业务访问，每天通过数据校验作业，比较两个平台的数据一致性。经过一段时间，确认数据没有问题后，再把对外访问的流量切换到新的数据平台，再经过一段时间撤除原有平台上的作业。对比方案可有多种：比较简单的如对比数据量，即分别统计出数据表的条数，然后进行比对。如果条数匹配，就认为两边数据是一致的。这种方法的优点是效率很高，缺点是不能完全保证数据的一致性。也可以采取对比数据条数加上关键字段校验，但需要提前定义出关键字段。也可以采取对全表做md5的方式，但这种方式只适合离线方式，且效率不高。
在完成上述过程后，可做应用迁移。如果是采取之前的混合新旧系统的方式，这个过程还是比较复杂的。建议使用内部的DevOPS平台或自研小工具完成，方便可随时查看对比及回退。
当完成全部数据迁移并通过测试后，可正式做系统割接。系统割接并不代表迁移完全成功，还是建议业务并行混跑，或旧系统仍然保持全量实时数据，随时可切换回去。这个过程是一个标志，标志从迁移阶段过渡到后期维护阶段。
在稳定运行一段时间后，会转为后期维护阶段。可定期对新系统做健康巡检，观察是否符合之前的预期。
3.迁移过后
迁移最终，必须针对此次迁移做个明确性的盘点。针对新系统整体表现，和之前的预期做对比评估。对依然存在的遗留问题，需要特别注意。
以上就是数据库如何迁移、数据库数据迁移方案步骤的介绍，希望对大家有帮助。
更多文章，请持续关注《MySql教程网》https://mysql360.com
