1. 数据迁移概述

数据迁移，是一个非常复杂的过程，不仅仅是将数据从一个地方移动到另一个地方。这里需要考虑业务定义、架构变更、应用改造、数据安全等诸多方面问题。在实际迁移工作中，需要结合企业的方方面面，做好合理的规划及实施，否则很可能会导致迁移结果达不到预期，浪费人力财力。在正式开始迁移之前，有几项工作是需要提前考虑的。

1).迁移目的
在我们正式开展迁移之前，首先要对迁移目的有个清晰的定位。后面的很多工作的前提，正基于此。下面罗列下常见的目的，真实场景中可能包含一个或多个的组合。

❖ 成本
现有方案成本过高，因而考虑至低成本方案。这里需要关注几点：

• 迁移后方案的总体成本，不仅要考虑初期采购成本，也要考虑后期维护及商业方案中过了初始几年后的持有成本。
• 迁移方案本身的成本，这里包括经济、时间、人力、风险成本等多种因素。

• 如实施失败时，必要的回退成本，包括因此而产生的对业务的影响所到来的经济损失。

  ❖ 性能
  现有方案不能满足性能要求，这里需要考虑几个问题：

• 性能要求是否合理？是常态化需求，还是偶然高峰？未来业务增长对性能的要求多大？
• 是否可在业务侧、应用侧，通过必要的改造、升级满足性能要求（毕竟前端的改造代价，比后端要小的多）？

• 是否可在原有数据平台上通过 Scale Up 或者 Scale Out 来解决性能问题？毕竟更换底层的平台的代价很大。

  ❖ 空间
  现有方案不能满足容量要求，这里需要考虑几个问题：

• 当前存量数据，是否可通过清理、转储、归档等手段，来减少现有容量？（水平拆分）
• 现有数据是否是同质的，即是否可通过分拆，划分出独立单元来承载业务？（垂直拆分）

• 现有存量使用及未来增量情况，这些对于未来选型都很重要。

  ❖ 自主可控
  随着近些年来，内外部环境和自上而下的政策性要求，对于企业核心技术的自主可控要求越来越高。因而对于国产化需求，日益高涨。

  ❖ 技术演进
  随着企业自身的技术发展，对于后端数据平台的要求不断变化。例如数据中台、微服务等兴起，作为数据载体也需求有所变化。

  ❖ 业务需求
  业务发展变化，也对于支撑平台的需求不断变化。

  ❖ 软硬件更换升级
  软件，技术更替、版本迭代；特别是硬件，有着明显的周期性特点。企业定期都会避免升级替换类诉求。

  2).业务场景分析
  在着手迁移之前，需要对现有业务做了全面的梳理，重点是将其对数据载体的要求整理清楚。为了满足这些业务场景，未来的迁移需求是通过单一平台还是通过多种异构组合来完成？这些内容对于后续迁移选型有着重要意义。在这个阶段，还需要增加对未来的增长变化或业务调整导致的可能变化。可以仿照下表，完成场景分析工作。
  
  3).迁移需求分析
  在对业务场景做好必要的分析工作后，我们还需要针对迁移需求做更多细致的工作。这里包括：

  ❖ 硬件环境
  业务系统使用的资源情况（ CPU 、 MEM 、 STORAGE 等）这些信息，一方面可用来为迁移后的技术选型做一定参考；另一方面在迁移阶段也需做好对现有环境影响的评估。

  ❖ 网络环境
  业务系统的网络配置和网络隔离情况，包括组网逻辑、带宽、隔离情况。这些对迁移实施，有着一定影响。

  ❖ 操作系统
  业务系统使用的操作系统，是Linux还是Windows，是32位还是64位，其使用的文件系统是什么？

  ❖ 安全策略
  业务系统的特殊安全要求，例如开放哪些端口、访问权限。

  ❖ 应用系统

  应用系统是采用商用的还是自研的，使用什么开发语言、版本是什么，接入类型（JDBC、ODBC等）？是否有专有的开发工具开发？是否使用了非标准接口？

  ❖ 数据规模
  包括整体的数据规模及设计最大规格，单体对象的最大规模（行、列）。数据特征（结构化 or 非结构化）、数据类型等。

  ❖ 数据安全指标
  RTO 、 RPO 等

  ❖ 性能指标
  MBPS 、 IOPS 、 RT 等

  4).迁移难点

  ❖ 数据安全
  数据是数据迁移的基本需求，如何在整个数据迁移操作过程中，保证数据的安全性是一项不小的挑战。除了考虑在迁移前必要的数据备份外，还要考虑清楚迁移过程中数据增量问题，以及出现异常问题后的安全回退等。

  ❖ 兼容性
  兼容性是整个数据迁移方案得以实施的前提。这里谈到的兼容性，不仅包括与原有业务应用系统的兼容，也包括与原有基础平台（监控、预警、备份）及其他数据平台的兼容。如存在不兼容之处，需要考虑之前的规避措施或做必要的调整。

❖ 停机时间
也就是业务迁移时间窗，这也常常是客户最关心的话题，很多情况下客户都是要求在线迁移。随着数据量日益扩大和业务的逐渐复杂，每次迁移停止和启动业务都需要消耗数小时时间，所以每一次数据迁移都是一场与时间赛跑的游戏，要求操作过程的全程可控。不仅要对正常流程的可控，还要做到在异常情况下的可控，保证即使出现各种异常，还能够正常时间内完成迁移或者回退。这里也要与客户充分的沟通，如果能使用离线迁移方式，还是建议使用离线方式，毕竟这种方式的风险要小很多。

❖ 数据校验
在整个的数据迁移过程中，采用的迁移方式多种多样。由于误操作或者迁移方案缺陷极有可能导致数据库数据的不一致。在迁移的过程中，应该制定严格的数据验证过程。在迁移前后，要有充分的准备。避免由于误操作导致数据库的数据库准确性问题。建议客户采用并行混跑方式，有较长的时间窗口可以充分验证新环境的数据准确性，避免出现发现异常而无法回退的情况。

❖ 性能保证
性能保证，也是客户比较关心的一个问题。能否对迁移后环境性能变现有个准确的预期，对客户来说尤为重要；但要做到准确的评估是比较困难的。一般建议在正式迁移之前，进行预迁移在全量数据环境下的模拟压力测试，验证性能表现。

2. 迁移过程：事前篇

1).方案调研
在迁移之前，最为重要的就是确定迁移方案。针对数据迁移，可以有很多类迁移方式，包括数据库、存储、虚拟机、卷、主机、网络、应用等等。这里需要根据我们的要求，圈定采用哪类迁移方式；然后是明确具体的迁移方案，如果涉及到外部商用方案，还需要进行必要的POC测试；再次就是细化方案，确定具体迁移步骤（含迁移、回退、验证）等。下面描述下常见的这几类迁移方案。

❖ 数据库方案
如果是同种数据库，可以采用备份、还原方式；异构的话，可以采用导入、导出方式。现在还有一种比较通用的方案，是消费源端的日志，将其转换成标准消息，然后对端消费应用。这种方式通用性较好，可实现同构、异构、跨平台的迁移；增量部分，通过源端的日志实时捕获，也可以实现。当然对于全量数据来说，还是建议采取异步方式，集中处理，这样效率比较高。

❖ 虚拟机方案
VMware、Hyper-V等虚拟化产品也都提供了在线替换迁移功能 。虚拟机的在线迁移功能可以实现无中断的迁移，但是并不是所有场景都可以使用这种方案进行迁移。因此虚拟机迁移需要首先核对是否场景限制上能够满足。

❖ 操作系统方案
对于文件系统场景，由于各个厂商的元数据结构不一样，一般都需要通过文件迁移工具从文件层进行拷贝和复制，保留文件的属性和权限，而不能从底层块数据层进行迁移。所以文件系统相对简单， 常见的诸如Linux下Rsync工具，就是一个远程数据同步工具，可通过 LA N或WAN 快速同步多台主机间的文件。

❖ 卷方案
在大多数操作系统上都提供卷管理软件，将SAN裸设备进行行聚合或者拆分后提供给上层应用使用，因此绝大多数应用数据都通过卷管理软件进行管理，所以卷管理软件自带的镜像和迁移功能常常成为在线数据迁移方案的一种选择。常见的如Linux下的LVM、Oracle自带的ASM等，通过这些不同的卷管理软件实现数据在线迁移到新的目标存储。

❖ 网络方案
虚拟化网关产品通过自带的存储虚拟化功能可以实现迁移功能。比如笔者之前使用过的EMC Vplex系列等。这种方式首先是通过虚拟化网产品将源存储接管，让源存储和业务主机之间的所有数据都通过网关产品进行传递，再通过网关产品将数据完整的从块级别镜像复制到目标新存储。 这种方案具有很强的普适性，可以在大部分的场景下使用 。但是由于镜像复制只是实现了数据复制到目标新存储，而原来的业务主机上的多路径，卷管理，集群和数据库等软件都是和源存储进行绑定的，因此在数据同步到目标存储的后，还需要将业务和源存储的绑定关系替换为目标存储，这个过程是整个数据迁移过程中最复杂的部分。

❖ 存储方案
存储设备本身也具备一些数据迁移功能，如LUN拷贝和远程复制。LUN拷贝可以把目标新存储作为一个服务器， 首先将源存储映射到目标新存储，再将目标新存储上的所有数据读出来写到目标存储上 。远程复制可以从数据块层面将数据从一台存储同步到远端的另一套存储，但一般要求源存储和目标存储都是来自一家的同平台产品。此功能经常被用于存储的跨地域数据迁移。

❖ 应用方案
应用方案，可以说是万能的方案，客户可根据自身情况定制迁移方案。其往往是最灵活的，当然也是复杂度相对较高的一种。常用的方法开发一个全量的迁移工具，进行数据迁移；增量部分，采用读取源端日志的方式补齐；此外配合必要的数据对比工具完成。在新旧系统数据基本同步后，断掉旧系统，切换到新系统。这种方式可以实现比较平滑的迁移，全程可控；但问题在于如果出现问题，还需考虑回退流程，最好能实现双向同步，但这种复杂度有增大不少。

还有一种就是所谓的“双写法”，先利用数据同步工具完成初始的数据同步，对于增量部分采用应用双写的方式完成，这里只要保证必要的数据幂等性即可。在切换流程上，通常采用六个阶段。

• 第一阶段，上线双写， 即同时写入新旧两种系统数据；
• 第二阶段，历史数据离线搬迁，即离线将历史存量数据从旧系统搬到新系统；
• 第三阶段，切读，即将读请求部分或全部路由到新系统；
• 第四阶段，切写，即将写请求部分或全部路由到新系统；
• 第五阶段，全部切换至新系统，即读写请求都走新系统，此时双写并没有停止，依然保证新旧两边的数据完全一致，目前是为了保证异常时可直接回切。视测试情况，这个阶段可保持较长时间，充分验证新系统的数据准确性、性能表现等。

• 第六阶段，停写，即将旧系统的写入停止，清理回收旧系统资源，全部流程结束。

  2).方案测试
  在明确了迁移方案后，需进行完备的方案测试；如涉及到自研部分，需尽早启动开发工作。如要采购外部产品，也需要在此阶段进行测试。这个阶段的测试，主要目的是验证方案可行性，特别是数据安全方面。对可能出现的风险，要充分评估，并将其纳入到后续方案细节中。此外，也需要在此阶段收集必要的性能数据，为后续评估新系统配置、停机窗口等，做必要的准备。如有多种方案均可行，也可以在测试阶段具体比较其差异，找出最为适合的一种。

3. 迁移过程：事中篇

在整体迁移过程中，一般遵循从规划阶段->准备阶段->迁移阶段->验证阶段->投产阶段的顺序。当在验证阶段出现问题时，可能需要回溯到规划阶段进行调整甚至放弃此方案；但投产阶段出现问题是，需要退回到验证阶段重新评测优化。（下面的迁移方案中，按照最为常见的数据库迁移方案进行说明）

1).规划阶段

❖ 总体规划
整个迁移过程会涉及数据库厂商、应用开发商、客户等多个部门和组织的配合，为了保证迁移项目的成功，每一个环节都要仔细分析并充分验证。总体规划尤为重要，建议成立虚拟的指挥中心协调各方资源推进。

❖ 资源规划
资源部分，主要是指迁移设计的硬件部分。包括硬件规划、选型、评测、采购等。如涉及多种设备（主机、存储、网络等），还需要考虑之间的兼容适配问题。此外，与现有平台的兼容能力也需考虑。如果涉及到国产化问题，还需要考虑上层软件的适配问题。

❖ 迁移规划
制定详细周密的迁移计划，包括整个后面“准备+迁移+验证+投产”的全流程。细节要详细到每一操作步骤，甚至要求全部脚本化，不能临时敲命令处理。所有步骤的预期结果，需要明示。在出现之前未评估结果时，需启动应急流程处理。此外，一定不要忽视回退计划。

❖ 测试规划
在迁移中的每一阶段，都要制定测试计划，做到步步可验证。这里的测试可从系统级、数据级、应用级、业务级多方面去考察，保证最后结果的正确性。

❖ 验收规划
在系统投产之后，需要有个标志性的环节，就是“验收”。这代表着本次迁移工作是否成功，可否将业务正式切换过来。一般建议，在系统上线投产后，一段时间之后再考虑。但需要在之前制定一个标准。

2).准备阶段

❖ 硬件环境
各种硬件的上架、联调，系统安装、部署等。

❖ 角色授权
在迁移之前开通必要的安全通路，开启可访问线上通路。

❖ 业务准备
业务端做好必要的准备，例如挂公告等，为正式迁移做好准备。

3).迁移阶段

❖ 权限迁移
这里包括用户、角色、权限迁移。需要考虑的是，原有这部分是否做调整，是否拆分、整合，是否做隔离。切记避免出现，可访问旧系统的情况，造成数据污染，乃至无法回退的情况。

❖ 对象迁移
也叫元数据迁移。这部分涉及内容很多，也是最为复杂的部分。常见包括以下一些方面：

• 字段类型

  如果是异构系统迁移，需要建立新旧系统的字段映射关系。对于无法直接映射的部分，要考虑如何转化实现。特别需要注意的是精度问题，不同数据库产品的相同类型字段，其精度有可能有差异。此外，还有诸如符号位等问题。可以提前做一个映射表，既方便查看，也方便研发人员对照。这部分也可利用一些工具辅助完成。

• 约束字段

  作为常见的五大类约束（PK、FK、UK、NULL、CHECK），是否在新平台全部原样支持。此外有些平台原生就不完全支持，此时要考虑好解决对策。此外，如果应用使用了业务主键，也要考虑迁移后是否有影响。

• 特殊字段

  在源或目标端，有一些特殊字段需要在对象迁移阶段给予关注。例如自增类型、分布键、分区键等。这些需要特殊考虑，往往需要人工指定。

• 字符集问题

  为避免出现导入后乱码等问题，需要在这个阶段就考虑。特别是如果目标端的字符集只能做到源端的子集的话，尤其需要注意。

• 其他类型

  其他诸如 临时表、虚拟列、序列、视图、存储过程、函数、触发器，索引等。这些在源端与目标端往往在实现上存在较大差异，主要注意甄别并解决。这也是对象迁移阶段，工作量最大的部分。如部分确实无法对应，可考虑在应用端实现类似的逻辑。

  ❖ 数据迁移
  数据迁移包括全量和增量数据迁移。具体方法可参照之前说明。 这里重点谈下迁移之后的数据校验问题，在完成新数据平台的搭建后，一般会和原有的数据平台并行运行一段时间，一方面是为了和原有平台进行业务和数据的比对，确保业务的正确性和连续性；另一方面，应用改造迁移是一个循序渐进的过程，在所有应用迁移完成前，原有数据平台还是要承担正常的业务访问。一般的做法是通过类似灰度发布的过程，开始的时候同时往两个平台写入数据，但只有原有数据平台对外提供业务访问，每天通过数据校验作业，比较两个平台的数据一致性。经过一段时间，确认数据没有问题后，再把对外访问的流量切换到新的数据平台，再经过一段时间撤除原有平台上的作业。 对比方案可有多种：比较简单的如对比数据量，即分别 统计出数据表的条数，然后进行比对。如果条数匹配，就认为两边数据是一致的。这种方法的优点是效率很高，缺点是不能完全保证数据的一致性。也可以采取对比数据条数加上关键字段校验，但需要提前定义出关键字段。也可以采取对全表做md5的方式，但这种方式只适合离线方式，且效率不高。

  ❖ 应用迁移
  在完成上述过程后，可做应用迁移。如果是采取之前的混合新旧系统的方式，这个过程还是比较复杂的。建议使用内部的DevOPS平台或自研小工具完成，方便可随时查看对比及回退。

  4).验证阶段

  ❖ 业务测试
  迁移完成后，首选需要进行的业务测试，即功能性验证。可采取全量回归的方式，尽量做到覆盖全部。重点关注异常，并定位是否是有迁移数据异常导致。

  ❖ 性能测试
  基于之前指定的性能指标，对迁移后的环境进行性能测试。这里最好是能有一组基线数据方便对比，可在预迁移的环境准备基线。这样新环境的种种性能指标，是可以很容易评估是否有异常。

  ❖ 问题修复
  迁移过程后，难免出现问题，需要在此阶段快速修复。

  ❖ 性能优化
  对于不满足性能要求的，可在线做性能优化。

  ❖ 培训辅导
  全部完成后，对客户人员进行必要的培训辅导。

  5).投产阶段

  ❖ 系统割接
  当完成全部数据迁移并通过测试后，可正式做系统割接。系统割接并不代表迁移完全成功，还是建议业务并行混跑，或旧系统仍然保持全量实时数据，随时可切换回去。这个过程是一个标志，标志从迁移阶段过渡到后期维护阶段。

  ❖ 运维保障
  进入运维保障阶段，还是建议全体人员在岗，特别是在头两个业务高峰期。要密切观察新系统的稳定性、性能等，并做好必要的记录，方便后期做迁移总结及正式运维交接。

  ❖ 后期维护
  在稳定运行一段时间后，会转为后期维护阶段。可定期对新系统做健康巡检，观察是否符合之前的预期。

4. 迁移过程：事后篇

迁移最后，需要针对此次迁移做个概括性的盘点。针对新系统的表现，与之前的预期进行对比评估。对仍然存在的遗留问题，需要重点关注。