企业如何做一次完美的数据迁移.docx

《企业如何做一次完美的数据迁移.docx》由会员分享，可在线阅读，更多相关《企业如何做一次完美的数据迁移.docx（17页珍藏版）》请在优知文库上搜索。

1、1.数据迁移概述数据迁移，是一个非常欠杂的过程，不仅仅是将数据从一个地方移动到另一个地方.这里需要考虑业务定义、架构变更、应用改造、数据安全等诸多方面问题.在实际迁移工作中，需要结合企业的方方面面，做好合理的规划及实施，否则很可能会导致迁移结果达不到预期，浪费人力财力.在正式开始迁移之前，有几项工作是需要提前考虑的。1） .迁移目的在我们正式开展迁移之前，首先要对迁移目的有个清晰的定位。后面的很多工作的前提，正基于此.下面罗列下常见的目的，真实场景中可能包含一个或多个的组合.成本现有方案成本过高，因而考虑至低成本方案.这里需要关注几点：迁移后方案的总体成本，不仅要考虑初期采购成本，也要考虑后期

2、维护及商业方案中过了初始几年后的持有成本.迁移方案本身的成本，这里包括经济、时间、人力、风睑成本等多种因素.如实施失败时，必要的回退成本，包括因此而产生的对业务的影响所到来的经济损失.性能现有方案不能满足性能要求，这里需要考虑几个问题：性能要求是否合理?是常态化需求，还是偶然高峰?未来业务增长对性能的要求多大？是否可在业务侧、应用侧，通过必要的改造、升级满足性能要求（毕竟前端的改造代价，比后端要小得多）？是否可在原有数据平台上通过ScaleUp或者ScaleOut来解决性能问题？毕竟更换底层的平台的代价很大。空间现有方案不能满足容量要求，这里需要考虑几个问题：当前存量数据，是否可通过清理、转博

3、、归档等手段，来减少现有容量？（水平拆分）现有数据是否是同质的，即是否可通过分拆，划分出独立单元来承载业务？（垂直拆分）现有存量使用及未来增量情况，这些对于未来选型都很重要.自主可控随着近些年来，内外部环境和自上而下的政策性要求，对于企业核心技术的自主可控要求越来越高.因而对于国产化需求，日益高涨.技术演进随着企业自身的技术发展，对于后端数据平台的要求不断变化.例如数据中台、微服务等兴起，作为数据载体需求也有所变化。业务需求业务发展变化，也对于支漳平台的需求不断变化。软硬件更换升级软件，技术更替、版本迭代；特别是硬件，有有明显的周期性特点.企业定期都会避免升级替换类诉求.2） .业务场景分析在

4、着手迁移之前，需要对现有业务做了全面的梳理，重点是将其对数据载体的要求整理清楚.为了满足这些业务场景，未来的迁移需求是通过单一平台还是通过多种异构组合来完成？这些内容对于后续迁移选型有有重要意义.在这个阶段，还需要增加对未来的增长变化或业务调整导致的可能变化.可以仿照下表,完成场景分析工作。应用场事ttKM*HV两化PB*-om10机Ii学习(*)WtP0*O*MtM(Will)SWtTB(104)MB(1000出200努繁场H（高开发）结构化TB(104)MB00“O-叨5003）迁移需求分析在对业务场景做好必要的分析工作后，我们还需要针对迁移需求做更多细致的工作.这里包括:硬件环境业务系统

5、使用的资源情况（CPU、MEM、STORAGE等）这些信息，一方面可用来为迁移后的技术选型做一定参考；另一方面在迁移阶段也需做好对现有环境影响的评估.网络环境业务系统的网络配置和网络隔离情况，包括组网逻辑、带宽、隔离情况,这些对迁移实施，有着一定影响.操作系统业务系统使用的操作系统，是1.inux还是Windows,是32位还是64位，其使用的文件系统是什么？安全策略业务系统的特殊安全要求，例如开放哪些端口、访问权限.应用系统应用系统是采用商用的还是自研的，使用什么开发语言、版本是什么，接入类型（JDBC、ODBC等）？是否有专有的开发工具开发？是否使用了非标准接口？数据规模包括整体的数据规模

6、及设计最大规格，单体对釜的最大规模（行、列）.数据特征（结构化or非结构化）、数据类型等.数据安全指标RTO、RPO等性能指标MBPS.IOPS、RT等4）.迁移难点数据安全数据是数据迁移的基本需求，如何在整个数据迁移麋作过程中，保证数据的安全性是一项不小的挑战.除了考虑在迁移前必要的数据备份外，还要考虑清楚迁移过程中数据增0问题，以及出现异常问题后的安全回退等.莪容性兼容性是整个数据迁移方案得以实施的前提.这里谈到的兼容性，不仅包括与原有业务应用系统的兼容，也包括与原有基础平台（监控、预警、备份）及其他数据平台的兼容.如存在不兼容之处，需要考虑之前的规避措施或做必要的调整.停机时间也就是业务

7、迁移时间窗，这也常常是客户最关心的话题,很多情况下客户都是要求在线迁移。随着数据量日益扩大和业务的逐渐且杂，每次迁移停止和启动业务都需要消耗数小时时间，所以每一次数据迁移都是一场与时间赛跑的游戏，要求操作过程的全程可控。不仅要对正常流程的可控，还要做到在异甫情况下的可控，保证即使出现各种异常,还能够正常时间内完成迁移或者回退.这里也要与客户充分的沟通，如果能使用离线迁移方式，还是建议使用离线方式，毕竟这种方式的风险要小很多.数据校验在整个的数据迁移过程中，采用的迁移方式多种多样.由于误探作或者迁移方案缺陷极有可能导致数据库数据的不一致.在迁移的过程中，应该制定严格的数据睑证过程.在迁移前后，要

8、有充分的准备.避免由于误操作导致数据库的数据席准确性问题。建议客户采用并行混跑方式，有较长的时间窗口可以充分验证新环境的数据准确性，避免出现发现异常而无法回退的情况.性能保证性能保证，也是客户比较关心的一个问题.能否对迁移后环境性能变现有个准确的预期，对客户来说尤为电要；但要做到准确的评估是比较困难的.一般建议在正式迁移之前，进行预迁移在全量数据环境下的模拟压力测试，验证性能表现.2.迁移过程：事前篇1) .方案调研在迁移之前，最为重要的就是确定迁移方案。针对数据迁移，可以有很多类迁移方式，包括数据库、存储、虚拟机.卷、主机、网络、应用等等.这里需要根据我们的要求，圈定采用哪类迁移方式；然后是

9、明确具体的迁移方案，如果涉及到外部商用方案，还需要进行必要的POC测试；再次就是细化方案，确定具体迁移步骤（含迁移、回退、验证）等.下面描述下常见的这几类迁移方案。数据库方案如果是同种数据库，可以采用备份、还原方式；异构的话，可以采用导入、导出方式.现在还有一种比较通用的方案，是消费源端的日志，将其转换成标准消息，然后对端消费应用。这种方式通用性较好，可实现同构、异构、跨平台的迁移；增最部分，通过源端的日志实时捕获，也可以实现.当然对于全量数据来说，还是建议采取异步方式，集中处理，这样效率比较高.虚拟机方案VMware.HyPer-V等虚拟化产品也都提供了在线替换迁移功能.虚拟机的在线迁移功能

10、可以实现无中断的迁移，但是并不是所有场景都可以使用这种方案进行迁移。因此虚拟机迁移需要首先核对是否场景限制上能够满足。操作系统方案对于文件系统场景，由于各个厂商的元数据结构不一样，一般都需要通过文件迁移工具从文件层进行拷贝和复制，保留文件的属性和权限，而不能从底层块数据层进行迁移.所以文件系统相对简单，常见的诸如1.inux下Rsync工具，就是一个远程数据同步工具，可通过1.AN或WAN快速同步多台主机间的文件.卷方案在大多数操作系统上都提供卷管理软件，将SAN裸设备进行行聚合或者拆分后提供给上层应用使用，因此绝大多数应用数据都通过卷管理软件进行管理，所以卷管理软件自带的镜像和迁移功能常常成

11、为在战数据迁移方案的一种选择.常见的如1.inux下的1.VM.Oracle自带的ASM等，通过这些不同的卷管理软件实现数据在线迁移到新的目标存储.网络方案虚拟化网关产品通过自带的存储虚拟化功能可以实现迁移功能.比如帝者之前使用过的EMCVPIeX系列等。这种方式首先是通过虚拟化网产品将源存储接管，让源存慵和业务主机之间的所有数据都通过网关产品进行传递，再通过网关产品将数据完整的从块级别镜像豆制到目标新存储。这种方案具有很强的普适性，可以在大部分的场景下使用但是由于镜像发制只是实现了数据复制到目标新存储，而原来的业务主机上的多路径，卷管理，集群和数据库等软件都是和源存储进行绑定的，因此在数据同

12、步到目标存储的后，还需要将业务和源存储的绑定关系替换为目标存储，这个过程是整个数据迁移过程中最豆杂的部分。存储方案存储设备本身也具备一些数据迁移功能，如1.UN拷贝和远程豆制.1.UN拷贝可以把目标新存储作为一个服务器，首先将源存储映射到目标新存储，再将目标新存储上的所有数据读出来写到目标存储上.远程豆制可以从数据块层面将数据从一台存储同步到远端的另一套存储，但一般要求源存储和目标存储都是来自一家的同平台产品.此功能经常被用于存储的跨地域数据迁移.应用方案应用方案，可以说是万能的方案，客户可根据自身情况定制迁移方案.其往往是最灵活的，当然也是夏杂度相对较高的一种.常用的方法开发一个全事的迁移工

13、具，进行数据迁移；增量部分，采用读取源端日志的方式补齐；此外配合必要的数据对比工具完成。在新旧系统数据基本同步后，断掉旧系统，切换到新系疣.这种方式可以实现比较平滑的迁移，全程可控；但问题在于如果出现问题,还需考虑回退流程，展好能实现双向同步，但这种复杂度又增大不少.还有一种就是所谓的“双写法，先利用数据同步工具完成初始的数据同步，对于增量部分采用应用双写的方式完成，这里只要保证必要的数据幕等性即可。在切换流程上，通常采用六个阶段.第一阶段，上线双写，即同时写入新旧两种系统数据；第二阶段，历史数据离线搬迁，即商线将历史存第数据从旧系统搬到新系统；第三阶段，切读，即将读请求部分或全部路由到新系统

14、;第四阶段，切写，即将写谙求部分或全部路由到新系统；第五阶段，全部切换至新系统，即读写请求都走新系统，此时双写并没有停止，依然保证新旧两边的数据完全一致，目前是为了保证异常时可直接回切.视测试情况，这个阶段可保持较长时间，充分验证新系统的数据准确性、性能表现等.第六阶段，停写，即将旧系统的写入停止，清理回收旧系统资源，全部流程结束.2) .方案测试在明确了迁移方案后，需进行完备的方案测试；如涉及到自研部分，需尽早启动开发工作。如要采购外部产品，也需要在此阶段进行测试。这个阶段的测试，主要目的是验证方案可行性，特别是数据安全方面.对可能出现的风险，要充分评估，并将其纳入到后续方案细节中.此外，也

15、需要在此阶段收集必要的性能数据，为后续评估新系统配置、停机窗口等，做必要的准备.如有多种方案均可行，也可以在测试阶段具体比较其差异，找出最为适合的一种。在整体迁移过程中,一般遵循从规划阶段-准备阶段-迁移阶段-验证阶段-投产阶段的峡序.当在的证阶段出现问题时，可能需要回溯到规划阶段进行调整甚至放弃此方案；但投产阶段出现问题是，需要退回到验证阶段电新评测优化.（下面的迁移方案中，按照最为常见的数据库迁移方案进行说明）“迁&0*0.0戌用过U付*优化1) .规划阶段总体规划整个迁移过程会涉及数据库厂商、应用开发商、客户等多个部门和组织的配合，为了保证迁移项目的成功，每一个环节都要仔细分析并充分验证.总体规划尤为由要，建议成立虚拟的指挥中心协调各方资源推进.资源规划资源部分，主要是指迁移设计的硬件部分.包括硬件规划、选型、评测、采购等.如涉及多种设备（主