认识达内从这里开始

云技术的应用随着互联网的不断发展而逐渐覆盖到了越来越多的企业，今天我们就通过案例分析来简单了解一下，云数据迁移都需要注意哪些问题。

一、关系型数据库

MySQL：

MySQL在迁移中为常见，也有很成熟的迁移工具和迁移方案，包括官方工具和相关开源工具，如mysqldump等，各个云厂商也都有各自的DTS迁移工具。

DTS工具：

DTS服务在传输及同步、数据校验等步骤都实现了一定的抽象化，具有相对友好的交互界面，同时可以实现多个任务并行进行，对要求平滑迁移的场景，具有自动化优势，节省大量人力，有部分DTS工具可以实现跨版本迁移。

DTS的限制是：

(1)源端数据库与目标端数据库与DTS管理服务IP网络互通，并具备稳定的网络连接。

(2)数据库需要满足一定的前提条件才能实现迁移后的增量同步功能，通常的需求是权限需求，比如REPLICATIONSLAVE,REPLICATION等，同时存储过程及函数在全量+增量的场景下不会被包含，在全量迁移阶段，不支持AlterTable、DropTableDDL操作，**不同厂家的工具限制条件可能不同，需要仔细阅读产品说明，并通过POC验证功能。

mysqldump工具：

适合的场景，数据库源端与目的端没有良好网络连接或无网络连接的情况下，允许有一定的业务中断时间，则在停机窗口完成数据导出、导入是比较适合的方案(如果具有主机级别的管理和控制能力，直接将数据库主机整体以镜像方式迁移也是一个可行的迁移方法)。

Mysqldump导出导入速度相对DTS要快(本地操作，而且与DTS相比，少了一些中间环节)，但是多了一个数据文件压缩及通过网络或移动介质传送的时间。

其他开源及商业工具，如streamset等，可以支持mysql到异构数据库的同步，功能比较强大，同时限制也比较多。

迁移时长的估算：

业务割接过程中，业务数据的迁移及同步是切换前的重要步骤，也是割接过程中耗时较长，容易出现错误并导致割接延时或失败的环节，因此要对数据迁移及同步耗时做出靠谱的估算。

数据库同步，是表级别的并发来迁移全量数据，因此，DTS得结合实际的数据类型、数据行数、网络带宽、网络延迟、同步实例规格，库表的数量、单库表的大小等因素评估时长。

二、ES迁移

ES应用越来越广泛，业务迁移中，ES数据迁移已经成为数据迁移的一个重要部分。

ES迁移技术涉及停服迁移及不停服迁移，不停服迁移对迁移的源端和目的端网络及服务有很多要求，目前实现起来尚有很多限制，目前一般只在集团内部业务做ES不停服迁移。

通常停服迁移技术路径可选择reindex或snapshot方式及logstash方式，几种方式均要参考官方对版本的要求，选择满足版本要求的迁移方式。

Snapshot方式：

Snapshot方式，从源ES集群创建数据快照，然后在目标ES集群中进行恢复。创建快照前必须先创建repository仓库，一个repository仓库可以包含多份快照文件。repository支持S3及共享文件存储系统等，自建的ES可以使用共享文件存储(从速度、成本等因素考虑，是佳选择)，使用公有云ES服务的建议采用支持S3协议的对象存储。

从速度和效率上来讲，快照方式优于reindex，当不需要对源端做任何变更，且网络存储条件具备时，优先选择快照方式迁移ES。

reindex是Elasticsearch提供的一个api接口，可以把数据从源ES集群导入到当前的ES集群，实现数据的迁移，reindex适用于数据量较大，有索引调整需求或无法连接共享存储的迁移场景，以及只需要迁移部分数据的场景。

reindex方式需要目标端能够访问到源端ES的服务端口。

三、业务数据迁移总结

1、提前做好备份，有了备份数据，迁移过程的压力会减小，相对宽松的迁移氛围对迁移实施很有利。

2、迁移技术及工具的选择，现在数据迁移工具越来越多，各个大厂也都有自己的工具，但是产品的限制及兼容程度各有不同，需要根据业务性质选择并验证。

3、准备回退预案，做好POC验证，POC能发现部分问题，提前准备解决方案。

4、做好流程手册，明确操作责任人，联系相关部门做好迁移的切换阶段的护航准备。产品和服务类的问题一定要能找到人支持。

5、明确责任矩阵、进行全面沟通，沟通能够发现技术层面很难发现的问题，越早建立迁移组织并形成有限的沟通机制，对迁移的顺利实施越有利。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。