1、数据迁移概述前端
数据迁移，是一个很是复杂的过程，不只仅是将数据从一个地方移动到另外一个地方。这里须要考虑业务定义、架构变动、应用改造、数据安全等诸多方面问题。在实际迁移工做中，须要结合企业的方方面面，作好合理的规划及实施，不然极可能会致使迁移结果达不到预期，浪费人力财力。在正式开始迁移以前，有几项工做是须要提早考虑的。数据库
一、迁移目的
在咱们正式开展迁移以前，首先要对迁移目的有个清晰的定位。后面的不少工做的前提，正基于此。下面罗列下常见的目的，真实场景中可能包含一个或多个的组合。后端
1）成本安全
现有方案成本太高，于是考虑至低成本方案。这里须要关注几点：性能优化
-
迁移后方案的整体成本，不只要考虑初期采购成本，也要考虑后期维护及商业方案中过了初始几年后的持有成本；服务器
-
迁移方案自己的成本，这里包括经济、时间、人力、风险成本等多种因素；网络
-
如实施失败时，必要的回退成本，包括所以而产生的对业务的影响所到来的经济损失。数据结构
2）性能架构
现有方案不能知足性能要求，这里须要考虑几个问题：运维
-
性能要求是否合理？是常态化需求，仍是偶然高峰？将来业务增加对性能的要求多大？
-
是否可在业务侧、应用侧，经过必要的改造、升级知足性能要求（毕竟前端的改造代价，比后端要小的多）？
-
是否可在原有数据平台上经过Scale Up或者Scale Out来解决性能问题？毕竟更换底层的平台的代价很大。
3）空间
现有方案不能知足容量要求，这里须要考虑几个问题：
-
当前存量数据，是否可经过清理、转储、归档等手段，来减小现有容量？（水平拆分）；
-
现有数据是不是同质的，便是否可经过分拆，划分出独立单元来承载业务？（垂直拆分）；
-
现有存量使用及将来增量状况，这些对于将来选型都很重要。
4）自主可控
随着近些年来，内外部环境和自上而下的政策性要求，对于企业核心技术的自主可控要求愈来愈高。于是对于国产化需求，日益高涨。
5）技术演进
随着企业自身的技术发展，对于后端数据平台的要求不断变化。例如数据中台、微服务等兴起，做为数据载体也需求有所变化。
6）业务需求
业务发展变化，也对于支撑平台的需求不断变化。
7）软硬件更换升级
软件，技术更替、版本迭代；特别是硬件，有着明显的周期性特色。企业按期都会避免升级替换类诉求。
二、业务场景分析
在着手迁移以前，须要对现有业务作了全面的梳理，重点是将其对数据载体的要求整理清楚。为了知足这些业务场景，将来的迁移需求是经过单一平台仍是经过多种异构组合来完成？这些内容对于后续迁移选型有着重要意义。在这个阶段，还须要增长对将来的增加变化或业务调整致使的可能变化。能够仿照下表，完成场景分析工做。
三、迁移需求分析
在对业务场景作好必要的分析工做后，咱们还须要针对迁移需求作更多细致的工做。这里包括：
1）硬件环境
业务系统使用的资源状况（CPU、MEM、STORAGE等）这些信息，一方面可用来为迁移后的技术选型作必定参考；另外一方面在迁移阶段也需作好对现有环境影响的评估。
2）网络环境
业务系统的网络配置和网络隔离状况，包括组网逻辑、带宽、隔离状况。这些对迁移实施，有着必定影响。
3）操做系统
业务系统使用的操做系统，是Linux仍是Windows，是32位仍是64位，其使用的文件系统是什么？
4）安全策略
业务系统的特殊安全要求，例如开放哪些端口、访问权限。
5）应用系统
应用系统是采用商用的仍是自研的，使用什么开发语言、版本是什么，接入类型（JDBC、ODBC等）？是否有专有的开发工具开发？是否使用了非标准接口？
6）数据规模
包括总体的数据规模及设计最大规格，单体对象的最大规模（行、列）。数据特征（结构化 or 非结构化）、数据类型等。
7）数据安全指标
RTO、RPO等。
8）性能指标
MBPS、IOPS、RT等。
四、迁移难点
1）数据安全
数据是数据迁移的基本需求，如何在整个数据迁移操做过程当中，保证数据的安全性是一项不小的挑战。除了考虑在迁移前必要的数据备份外，还要考虑清楚迁移过程当中数据增量问题，以及出现异常问题后的安全回退等。
2）兼容性
兼容性是整个数据迁移方案得以实施的前提。这里谈到的兼容性，不只包括与原有业务应用系统的兼容，也包括与原有基础平台（监控、预警、备份）及其余数据平台的兼容。如存在不兼容之处，须要考虑以前的规避措施或作必要的调整。
3）停机时间
也就是业务迁移时间窗，这也经常是客户最关心的话题，不少状况下客户都是要求在线迁移。随着数据量日益扩大和业务的逐渐复杂，每次迁移中止和启动业务都须要消耗数小时时间，因此每一次数据迁移都是一场与时间赛跑的游戏，要求操做过程的全程可控。不只要对正常流程的可控，还要作到在异常状况下的可控，保证即便出现各类异常，还可以正常时间内完成迁移或者回退。这里也要与客户充分的沟通，若是能使用离线迁移方式，仍是建议使用离线方式，毕竟这种方式的风险要小不少。
4）数据校验
在整个的数据迁移过程当中，采用的迁移方式多种多样。因为误操做或者迁移方案缺陷极有可能致使数据库数据的不一致。在迁移的过程当中，应该制定严格的数据验证过程。在迁移先后，要有充分的准备。避免因为误操做致使数据库的数据库准确性问题。建议客户采用并行混跑方式，有较长的时间窗口能够充分验证新环境的数据准确性，避免出现发现异常而没法回退的状况。
5）性能保证
性能保证，也是客户比较关心的一个问题。可否对迁移后环境性能变现有个准确的预期，对客户来讲尤其重要；但要作到准确的评估是比较困难的。通常建议在正式迁移以前，进行预迁移在全量数据环境下的模拟压力测试，验证性能表现。
2、迁移过程：事前篇
一、方案调研
在迁移以前，最为重要的就是肯定迁移方案。针对数据迁移，能够有不少类迁移方式，包括数据库、存储、虚拟机、卷、主机、网络、应用等等。这里须要根据咱们的要求，圈定采用哪类迁移方式；而后是明确具体的迁移方案，若是涉及到外部商用方案，还须要进行必要的POC测试；再次就是细化方案，肯定具体迁移步骤（含迁移、回退、验证）等。下面描述下常见的这几类迁移方案。
1）数据库方案
若是是同种数据库，能够采用备份、还原方式；异构的话，能够采用导入、导出方式。如今还有一种比较通用的方案，是消费源端的日志，将其转换成标准消息，而后对端消费应用。这种方式通用性较好，可实现同构、异构、跨平台的迁移；增量部分，经过源端的日志实时捕获，也能够实现。固然对于全量数据来讲，仍是建议采起异步方式，集中处理，这样效率比较高。
2）虚拟机方案
VMware、Hyper-V等虚拟化产品也都提供了在线替换迁移功能。虚拟机的在线迁移功能能够实现无中断的迁移，可是并非全部场景均可以使用这种方案进行迁移。所以虚拟机迁移须要首先核对是否场景限制上可以知足。
3）操做系统方案
对于文件系统场景，因为各个厂商的元数据结构不同，通常都须要经过文件迁移工具从文件层进行拷贝和复制，保留文件的属性和权限，而不能从底层块数据层进行迁移。因此文件系统相对简单，常见的诸如Linux下Rsync工具，就是一个远程数据同步工具，可经过 LAN或WAN 快速同步多台主机间的文件。
4）卷方案
在大多数操做系统上都提供卷管理软件，将SAN裸设备进行行聚合或者拆分后提供给上层应用使用，所以绝大多数应用数据都经过卷管理软件进行管理，因此卷管理软件自带的镜像和迁移功能经常成为在线数据迁移方案的一种选择。常见的如Linux下的LVM、Oracle自带的ASM等，经过这些不一样的卷管理软件实现数据在线迁移到新的目标存储。
5）网络方案
虚拟化网关产品经过自带的存储虚拟化功能能够实现迁移功能。好比笔者以前使用过的EMC Vplex系列等。这种方式首先是经过虚拟化网产品将源存储接管，让源存储和业务主机之间的全部数据都经过网关产品进行传递，再经过网关产品将数据完整的从块级别镜像复制到目标新存储。
这种方案具备很强的普适性，能够在大部分的场景下使用。可是因为镜像复制只是实现了数据复制到目标新存储，而原来的业务主机上的多路径，卷管理，集群和数据库等软件都是和源存储进行绑定的，所以在数据同步到目标存储的后，还须要将业务和源存储的绑定关系替换为目标存储，这个过程是整个数据迁移过程当中最复杂的部分。
6）存储方案
存储设备自己也具有一些数据迁移功能，如LUN拷贝和远程复制。LUN拷贝能够把目标新存储做为一个服务器，首先将源存储映射到目标新存储，再将目标新存储上的全部数据读出来写到目标存储上。远程复制能够从数据块层面将数据从一台存储同步到远端的另外一套存储，但通常要求源存储和目标存储都是来自一家的同平台产品。此功能常常被用于存储的跨地域数据迁移。
7）应用方案
应用方案，能够说是万能的方案，客户可根据自身状况定制迁移方案。其每每是最灵活的，固然也是复杂度相对较高的一种。经常使用的方法开发一个全量的迁移工具，进行数据迁移；增量部分，采用读取源端日志的方式补齐；此外配合必要的数据对比工具完成。在新旧系统数据基本同步后，断掉旧系统，切换到新系统。这种方式能够实现比较平滑的迁移，全程可控；但问题在于若是出现问题，还需考虑回退流程，最好能实现双向同步，但这种复杂度有增大很多。
还有一种就是所谓的“双写法”，先利用数据同步工具完成初始的数据同步，对于增量部分采用应用双写的方式完成，这里只要保证必要的数据幂等性便可。在切换流程上，一般采用六个阶段。
-
第一阶段，上线双写，即同时写入新旧两种系统数据；
-
第二阶段，历史数据离线搬迁，即离线将历史存量数据从旧系统搬到新系统；
-
第三阶段，切读，即将读请求部分或所有路由到新系统；
-
第四阶段，切写，即将写请求部分或所有路由到新系统；
-
第五阶段，所有切换至新系统，即读写请求都走新系统，此时双写并无中止，依然保证新旧两边的数据彻底一致，目前是为了保证异常时可直接回切。视测试状况，这个阶段可保持较长时间，充分验证新系统的数据准确性、性能表现等。
-
第六阶段，停写，即将旧系统的写入中止，清理回收旧系统资源，所有流程结束。
二、方案测试
在明确了迁移方案后，需进行完备的方案测试；如涉及到自研部分，需尽早启动开发工做。如要采购外部产品，也须要在此阶段进行测试。这个阶段的测试，主要目的是验证方案可行性，特别是数据安全方面。对可能出现的风险，要充分评估，并将其归入到后续方案细节中。
此外，也须要在此阶段收集必要的性能数据，为后续评估新系统配置、停机窗口等，作必要的准备。若有多种方案都可行，也能够在测试阶段具体比较其差别，找出最为适合的一种。
3、迁移过程：事中篇
在总体迁移过程当中，通常遵循从规划阶段->准备阶段->迁移阶段->验证阶段->投产阶段的顺序。当在验证阶段出现问题时，可能须要回溯到规划阶段进行调整甚至放弃此方案；但投产阶段出现问题是，须要退回到验证阶段从新评测优化。（下面的迁移方案中，按照最为常见的数据库迁移方案进行说明）。
一、规划阶段
1）整体规划
整个迁移过程会涉及数据库厂商、应用开发商、客户等多个部门和组织的配合，为了保证迁移项目的成功，每个环节都要仔细分析并充分验证。整体规划尤其重要，建议成立虚拟的指挥中心协调各方资源推动。
2）资源规划
资源部分，主要是指迁移设计的硬件部分。包括硬件规划、选型、评测、采购等。如涉及多种设备（主机、存储、网络等），还须要考虑之间的兼容适配问题。此外，与现有平台的兼容能力也需考虑。若是涉及到国产化问题，还须要考虑上层软件的适配问题。
3）迁移规划
制定详细周密的迁移计划，包括整个后面“准备+迁移+验证+投产”的全流程。细节要详细到每一操做步骤，甚至要求所有脚本化，不能临时敲命令处理。全部步骤的预期结果，须要明示。在出现以前未评估结果时，需启动应急流程处理。此外，必定不要忽视回退计划。
4）测试规划
在迁移中的每一阶段，都要制定测试计划，作到步步可验证。这里的测试可从系统级、数据级、应用级、业务级多方面去考察，保证最后结果的正确性。
5）验收规划
在系统投产以后，须要有个标志性的环节，就是“验收”。这表明着本次迁移工做是否成功，能否将业务正式切换过来。通常建议，在系统上线投产后，一段时间以后再考虑。但须要在以前制定一个标准。
二、准备阶段
1）硬件环境
各类硬件的上架、联调，系统安装、部署等。
2）角色受权
在迁移以前开通必要的安全通路，开启可访问线上通路。
3）业务准备
业务端作好必要的准备，例如挂公告等，为正式迁移作好准备。
三、迁移阶段
1）权限迁移
这里包括用户、角色、权限迁移。须要考虑的是，原有这部分是否作调整，是否拆分、整合，是否作隔离。切记避免出现，可访问旧系统的状况，形成数据污染，乃至没法回退的状况。
2）对象迁移
也叫元数据迁移。这部分涉及内容不少，也是最为复杂的部分。常见包括如下一些方面：
①字段类型
若是是异构系统迁移，须要创建新旧系统的字段映射关系。对于没法直接映射的部分，要考虑如何转化实现。特别须要注意的是精度问题，不一样数据库产品的相同类型字段，其精度有可能有差别。此外，还有诸如符号位等问题。能够提早作一个映射表，既方便查看，也方便研发人员对照。这部分也可利用一些工具辅助完成。
②约束字段
做为常见的五大类约束（PK、FK、UK、NULL、CHECK），是否在新平台所有原样支持。此外有些平台原生就不彻底支持，此时要考虑好解决对策。此外，若是应用使用了业务主键，也要考虑迁移后是否有影响。
③特殊字段
在源或目标端，有一些特殊字段须要在对象迁移阶段给予关注。例如自增类型、分布键、分区键等。这些须要特殊考虑，每每须要人工指定。
④字符集问题
为避免出现导入后乱码等问题，须要在这个阶段就考虑。特别是若是目标端的字符集只能作到源端的子集的话，尤为须要注意。
⑤其余类型
其余诸如临时表、虚拟列、序列、视图、存储过程、函数、触发器，索引等。这些在源端与目标端每每在实现上存在较大差别，主要注意甄别并解决。这也是对象迁移阶段，工做量最大的部分。如部分确实没法对应，可考虑在应用端实现相似的逻辑。
3）数据迁移
数据迁移包括全量和增量数据迁移。具体方法可参照以前说明。这里重点谈下迁移以后的数据校验问题，在完成新数据平台的搭建后，通常会和原有的数据平台并行运行一段时间，一方面是为了和原有平台进行业务和数据的比对，确保业务的正确性和连续性；另外一方面，应用改造迁移是一个按部就班的过程，在全部应用迁移完成前，原有数据平台仍是要承担正常的业务访问。通常的作法是经过相似灰度发布的过程，开始的时候同时往两个平台写入数据，但只有原有数据平台对外提供业务访问，天天经过数据校验做业，比较两个平台的数据一致性。
通过一段时间，确认数据没有问题后，再把对外访问的流量切换到新的数据平台，再通过一段时间撤除原有平台上的做业。对比方案可有多种：比较简单的如对比数据量，即分别统计出数据表的条数，而后进行比对。若是条数匹配，就认为两边数据是一致的。这种方法的优势是效率很高，缺点是不能彻底保证数据的一致性。也能够采起对比数据条数加上关键字段校验，但须要提早定义出关键字段。也能够采起对全表作md5的方式，但这种方式只适合离线方式，且效率不高。
4）应用迁移
在完成上述过程后，可作应用迁移。若是是采起以前的混合新旧系统的方式，这个过程仍是比较复杂的。建议使用内部的DevOps平台或自研小工具完成，方即可随时查看对比及回退。
四、验证阶段
1）业务测试
迁移完成后，首选须要进行的业务测试，即功能性验证。可采起全量回归的方式，尽可能作到覆盖所有。重点关注异常，并定位是不是有迁移数据异常致使。
2）性能测试
基于以前指定的性能指标，对迁移后的环境进行性能测试。这里最好是能有一组基线数据方便对比，可在预迁移的环境准备基线。这样新环境的种种性能指标，是能够很容易评估是否有异常。
3）问题修复
迁移过程后，不免出现问题，须要在此阶段快速修复。
4）性能优化
对于不知足性能要求的，可在线作性能优化。
5）培训辅导
所有完成后，对客户人员进行必要的培训辅导。
五、投产阶段
1）系统割接
当完成所有数据迁移并经过测试后，可正式作系统割接。系统割接并不表明迁移彻底成功，仍是建议业务并行混跑，或旧系统仍然保持全量实时数据，随时可切换回去。这个过程是一个标志，标志从迁移阶段过渡到后期维护阶段。
2）运维保障
进入运维保障阶段，仍是建议全体人员在岗，特别是在头两个业务高峰期。要密切观察新系统的稳定性、性能等，并作好必要的记录，方便后期作迁移总结及正式运维交接。
3）后期维护
在稳定运行一段时间后，会转为后期维护阶段。可按期对新系统作健康巡检，观察是否符合以前的预期。
4、迁移过程：过后篇
迁移最后，须要针对这次迁移作个归纳性的盘点。针对新系统的表现，与以前的预期进行对比评估。对仍然存在的遗留问题，须要重点关注。