云服务器与云服务器该怎么迁移数据?
发布网友
发布时间：2024-09-17 21:39
共1个回答
热心网友
时间：2024-09-21 00:27
业务迁移上云涉及到的业务数据种类繁多，主要类型包括： 数据库： 关系型数据库 MySQL 、PG、Oracle等 对象存储： 标准S3接口对象存储迁移中间件数据：ES、mongoDB、redis等 文件存储：文档、图片等非结构化数据 大数据：HBASE、HDFS files等。
在上云过程中，大部分业务均涉及到以上多种数据类型，基于相关迁移的案例所积累的经验，数据迁移需要在迁移启动前至少做好如下准备工作。 数据迁移技术方案制定完成，包含明确的迁移操作步骤、执行人、确认人。 制定迁移应急预案及回切方案，明确责任矩阵，确认异常情况的决策条件及决策人。 确认数据安全等级，确认数据迁移的方案合规安全，通过相关业务安全部门审核。 迁移时长及割接数据同步窗口的评估，确认各个业务及数据迁移可选的第二方案。 确认网络带宽及质量满足迁移需求。
下面是几个案例，涉及到了不同数据迁移的场景。 关系型数据库迁移：MySQL 数据迁移工具DTS服务在传输及同步、数据校验等步骤实现了一定的抽象化，具有相对友好的交互界面，同时可以实现多个任务并行进行，对要求平滑迁移的场景，具有自动化优势，节省大量人力，但需要满足源端数据库与目标端数据库与DTS管理服务IP网络互通，并具备稳定的网络连接。 mysqlmp工具适合于网络连接不佳或需要一定业务中断时间的场景，本地操作速度快，但需要考虑数据文件的传输时间。 DTS与mysqlmp工具都有各自的*条件，需要仔细阅读产品说明，并通过POC验证功能。
案例一：从友商公有云迁移到京东云公有云，由于源端binlog问题导致DTS任务失败，最终通过mysqlmp模式导出文件，本地导出速度很快，压缩后的数据库导出文件体积缩小，减少了网络传输耗时。通过网络传输到京东云侧的云主机，然后source方式导入RDS，整个过程耗时小于2小时。导入MySQL数据后，使用checksum_table工具对源端和目的端数据库做对比，发现部分表不一致，与业务方确认为源端在迁移开始后，停止服务不彻底导致，仍然有数据写入操作，后经业务及研发检查新增数据，对部分数据做清理后，完成数据库的迁移工作。
厂商改良（非原生）的数据库的迁移：在某些云厂商的特定数据库版本中，会对标准的数据库产品如mariaDB、PG等数据库做一些定制化的开发，以满足客户的业务的某些特殊需求，这种数据库属于厂家深度绑定的类型，在做业务迁移或灾备数据同步的时候，根据时间场景做定制化的迁移及同步方案，大部分需要从研发层面做一些定制化的配置和操作。
案例二：某金融用户，原系统运行于T的金融云，使用了定制化的RDS服务，因金融行业的业务及数据灾备规范，需要做异地容灾，将灾备系统运行于京东金融云平台。为实现从T云定制化的TDSQL到京东云的迁移，对源端的数据库做了详细调研，因为源端是定制化的、具有自动水平拆分、Shared Nothing 架构的分布式数据库，因此使用京东云的DTS工具不适用于这个场景，同时，在两个环境，要求数据基本为实时同步才能满足业务容灾的需求。制定方案时，考虑了传统灾备厂商的方案，但因传统厂商灾备方案多以主机级别数据及IO分析或日志分析为基础，无法适应云上RDS的场景，最终方案采取了基于gtid的主从复制的方案来实现数据库的异构云同步。
案例三：客户业务从友商云迁移到京东云，源端ES为K8S集群自建服务，服务访问方式为nodeport方式，选择迁移技术方案时，考虑了源端自建的ES未安装S3插件，因此采取reindex方式来做业务数据的迁移。为实现从京东云侧对ES的数据拉取，在源端配置了一个nginx反向代理，实现了通过公网对内部ES接口的访问，同时配置白名单，*访问IP为京东侧NAT网关出口的公网IP，确保数据的访问安全。在京东云侧，临时调整路由表，配置明细路由，将源端公网IP配置到对应子网的路由表中，指向NAT网关，通过NAT网关可以拉取到源侧的ES数据，并在ES服务中对源端的公网IP做加白操作。
对象存储的迁移：对兼容S3协议的对象存储数据迁移，各个公有云厂商均有迁移工具或脚本，迁移技术难度不高。但是，因为不同厂家的对象存储在不同region可能存在底层版本及配置差异，因此需要对迁移的数据做完整性和可用性校验。在实际迁移中，需要根据项目实际的数据存储量、业务访问特性、业务停机窗口等信息，综合考虑迁移流程和选择技术方案。
Redis迁移：业务中Redis使用有两种场景，一种是仅作为缓存，不做数据持久化，这种业务场景，迁移后在新环境部署业务后直接调整业务指向新的redis实例即可。一种是有数据持久化，这种业务在迁移到云上时，需要根据业务需求，做redis数据的迁移操作。Redis有rdb（point-in-time snapshot）和aof两种持久化方案，其中rdb模式是二进制格式，类似于快照，恢复直接覆盖，aof保存的是命令（文本格式），类似于追加模式。如果需要保留目标端的redis的数据，可以使用aof方式，但需要注意老版本Redis服务不兼容新版RDB格式。
数据备份的重要性：数据备份是在业务迁移的全生命周期怎么强调都不过分的环节，因数据备份不充分导致数据丢失、业务受损的教训很多。在迁移实施过程中，因忽视数据备份而导致出现问题的事件仍然很常见。问题可能来自客户，可能来自我们实施团队，也可能来自ISV或者其他可能操作数据的团队或个人。在重要业务场景中，迁移前，需要对数据备份所需的存储空间做好评估并考虑备份空间的成本。
业务数据迁移总结：提前做好备份，有了备份数据，迁移过程的压力会减小，相对宽松的迁移氛围对迁移实施很有利。迁移技术及工具的选择，需要根据业务性质选择并验证。准备回退预案，做好POC验证，POC能发现部分问题，提前准备解决方案。做好流程手册，明确操作责任人，联系相关部门做好迁移的切换阶段的护航准备。产品和服务类的问题一定要能找到人支持。明确责任矩阵、进行全面沟通，沟通能够发现技术层面很难发现的问题，越早建立迁移组织并形成有限的沟通机制，对迁移的顺利实施越有利。
致谢：本文写作过程中，京东科技-京东云RDS研发同事、京东科技-京东云对象存储研发同事、京东零售-企业业务事业群的研发同事提供了宝贵资料和建议。向他们表示衷心地感谢。
