共计 9722 个字符，预计需要花费 25 分钟才能阅读完成。
前言
在反对京东团体外部及京东云内部客户的业务迁徙到京东私有云及京东公有云、京东政务云的过程中，京东科技 - 京东云事业群 - 技术服务组积攒了相干业务零碎数据迁徙的一些治理和技术教训，以案例的模式分享给大家，心愿对大家的业务迁徙工作有所帮忙。
迁徙前的筹备工作
业务迁徙上云波及到的业务数据品种繁多，次要类型包含：
数据库：
关系型数据库 MySQL、PG、Oracle 等
对象存储：
规范 S3 接口对象存储迁徙中间件数据：ES、mongoDB、redis 等
文件存储：
文档、图片等非结构化数据
大数据：
HBASE、HDFS files 等
京东云的内外部客户在上云过程中，大部分业务均波及到以上多种数据类型，基于相干迁徙的案例所积攒的教训，数据迁徙须要在迁徙启动前至多做好如下筹备工作。
1、可执行的数据迁徙技术计划制订实现，蕴含明确的迁徙操作步骤（迁徙前筹备工作，迁徙操作、迁徙后校验工作）、执行人、确认人。
2、制订迁徙应急预案及回切计划，明确责任矩阵，确认异常情况的决策条件及决策人。
3、确认数据安全等级，确认数据迁徙的计划合规平安，通过相干业务安全部门审核。
4、迁徙时长及割接数据同步窗口的评估（以 POC 验证数据信息为根底制订），确认各个业务及数据迁徙可选的第二计划。
5、确认网络带宽及品质满足迁徙需要。
案例剖析
上面是几个案例，波及到了不同数据迁徙的场景。
一、关系型数据库
MySQL：
MySQL 在迁徙中最为常见，也有很成熟的迁徙工具和迁徙计划，包含官网工具和相干开源工具，如 mysqldump 等，各个云厂商也都有各自的 DTS 迁徙工具。
DTS 工具：
DTS 服务在传输及同步、数据校验等步骤都实现了肯定的抽象化，具备绝对敌对的交互界面，同时能够实现多个工作并行进行，对要求平滑迁徙的场景，具备自动化劣势，节俭大量人力，有局部 DTS 工具能够实现跨版本迁徙。
DTS 的限度是：
（1）源端数据库与指标端数据库与 DTS 治理服务 IP 网络互通，并具备稳固的网络连接。
（2）数据库须要满足肯定的前提条件能力实现迁徙后的增量同步性能，通常的需要是权限需要，比方 REPLICATION SLAVE,REPLICATION 等，同时存储过程及函数在全量 + 增量的场景下不会被蕴含，在全量迁徙阶段，不反对 Alter Table、Drop Table DDL 操作，** 不同厂家的工具限度条件可能不同，须要仔细阅读产品阐明，并通过 POC 验证性能。
mysqldump 工具：
适宜的场景，数据库源端与目标端没有良好网络连接或无网络连接的状况下，容许有肯定的业务中断工夫，则在停机窗口实现数据导出、导入是比拟适宜的计划（如果具备主机级别的治理和控制能力，间接将数据库主机整体以镜像形式迁徙也是一个可行的迁徙办法）。
Mysqldump 导出导入速度绝对 DTS 要快（本地操作，而且与 DTS 相比，少了一些中间环节），然而多了一个数据文件压缩及通过网络或挪动介质传送的工夫。
其余开源及商业工具，如 streamset 等，能够反对 mysql 到异构数据库的同步，性能比拟弱小，同时限度也比拟多。
迁徙时长的估算：
业务割接过程中，业务数据的迁徙及同步是切换前的重要步骤，也是割接过程中耗时较长，容易呈现谬误并导致割接延时或失败的环节，因而要对数据迁徙及同步耗时做出靠谱的估算。
数据库同步，是表级别的并发来迁徙全量数据，因而，DTS 得结合实际的数据类型、数据行数、网络带宽、网络提早、同步实例规格，库表的数量、单库表的大小等因素评估时长。
举例来说，数据库大小 500G，有 5 张表，其中一个单表 400G，剩下 4 张表 各 25G，因单表 400G 绝对较大，迁徙时长会拉长。如果是 5 个 100G 的表，迁徙时长会缩减。
在正式迁徙生产数据前，个别会有对测试环境的迁徙 POC，来验证和评估生产环境的切换流程及耗时，制订生产业务割接的打算时，要以这个工夫为数据库迁徙的时长根据。
京东云 DTS 数据迁徙同步架构如下图：
案例一
从友商私有云迁徙到京东私有云云，因为源端 binlog 问题导致的一次 DTS 迁徙到手动迁徙形式的转换。
我的项目条件，业务具备 8 小时的停服工夫，因而在迁徙技术计划 DTS 及手动导数据库都是可选计划，鉴于 DTS 的不停服及数据增量性能个性，咱们抉择在停服前开始通过京东云 DTS 服务同步历史数据，并开启 DTS 增量同步性能，基于停机窗口，咱们给数据库在线迁徙及增量同步的工夫为 4 小时，DTS 服务不影响在线业务，基于测试环境的迁徙教训及评估。
在停服前的下午，为了给迁徙留出足够的工夫缓冲，咱们提前启动了主数据库的 DTS 服务，数据库迁徙过程失常进行，预计迁徙时长为 4 小时，然而在 DTS 服务最初阶段，因源端 binlog 问题，呈现了一个致命谬误，导致 DTS 工作失败。
Migration Task Run Error
ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.
Region: cn-north-1
ClusterGID: dts-r1rroa
ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.
因为最终 binlog 谬误（局部 binglog 失落），DTS 工作无奈复原，最终 DTS 传输的 4 小时工夫被节约，因迁徙是系统工程，其余数据迁徙过程也都在依据打算推动，此时大家都没有工夫去剖析具体起因。
因到早晨客户业务曾经推送告诉并停服，此时业务迁徙的其余数据迁徙及业务调试曾经开始。
所以，毅然决然决定以 mysqldump 模式导出文件，本地导出速度很快（20M/s），压缩后的数据库导出文件体积放大，缩小了网络传输耗时。通过网络传输到京东云侧的云主机，而后 source 形式导入 RDS。导出、传输、导入整个过程耗时小于 2 小时。
导入 MySQL 数据后，依据迁徙流程做迁徙数据校验，应用 checksum_table 工具对源端和目标端数据库做比照。
源库信息：—src-host sourceIP —src-user user —src-pass pass
指标库信息：—dest-host targetURL —dest-user user —dest-pass pass
验证过程中，发现局部表不统一，与业务方确认为源端在迁徙开始后，进行服务不彻底导致，依然有数据写入操作，因为业务侧并没有依据迁徙标准查看 mq、kafka 的音讯产生状况，只是进行了局部服务，后经业务及研发查看新增数据，对局部数据做清理后，实现数据库的迁徙工作。
依据我的项目教训，这种 DTS 服务因 binlog 问题导致的失败状况并非个案。
筹备工作
（1）为数据库迁徙筹备一个备选计划并筹备好应急预案。
（2）呈现问题时，决策条件及决策人提前确认，在施行过程中能依据须要及时决策做出调整。
厂商改进（非原生）的数据库的迁徙：
在某些云厂商的特定数据库版本中，会对规范的数据库产品如 mariaDB、PG 等数据库做一些定制化的开发，以满足客户的业务的某些非凡需要，这种数据库属于厂家深度绑定的类型，在做业务迁徙或灾备数据同步的时候，依据工夫场景做定制化的迁徙及同步计划，大部分须要从研发层面做一些定制化的配置和操作。
案例二
某金融用户，原零碎运行于 T 的金融云，应用了定制化的 RDS 服务，因金融行业的业务及数据灾备标准，须要做异地容灾，指标为实现业务级别灾备，将灾备零碎运行于京东金融云平台。
为实现从 T 云定制化的 TDSQL 到京东云的迁徙，对源端的数据库做了具体调研，因为源端是定制化的、具备主动程度拆分、Shared Nothing 架构的分布式数据库，因而应用京东云的 DTS 工具不适用于这个场景，同时，在两个环境，要求数据根本为实时同步能力满足业务容灾的需要。
制定方案
在制订数据同步计划时，也对传统灾备厂商的计划做了调研，因传统厂商灾备计划多以主机级别数据及 IO 剖析或日志剖析为根底，须要做一些侵入式 agent 的装置，与云上 RDS 的场景无奈适配，相干厂商也示意正在做向云上灾备的转型，但尚未有成熟落地的产品（适配难度较大），因而最终计划采取了基于 gtid 的主从复制的计划来实现数据库的异构云同步，屏蔽了架构差别带来的问题。
留神：波及业务信息及底层操作的局部内容曾经隐去。
- 首先对源端做权限调整：
GRANT SELECT, RELOAD, SHOW DATABASES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, SHOW VIEW ON . TO‘user’@’192.168.%’ - 对源端做全量的逻辑备份：
mysqldump –h xx –uusername -p –database nx_db -f —single-transaction —master-data=2 —skip-lock-tables > /data1/bs.dmp
留神导出文件中要有 gtid 信息。 - 灾备端导入：
mysql –h xx -f –uusername -p < bs.dmp - 后盾做复制配置：
set gtid_slave_pos=’0-13381-1xxxx06’;
CHANGE MASTER TO MASTER_HOST=’sourceIP’,MASTER_USER=’username’,MASTER_PASSWORD=’*‘,MASTER_USE_GTID=’slave_pos’; - 同步验证
- 数据验证
（1）业务侧进行写操作，在 T 云侧和京东云侧别离通过 checksum table tablename 对要害表做校验。
（2）业务侧在 T 云 / 京东云两边别离执行命令，对表 /view 等做数量校验：
select count(1) from information_schema.tables where table_schema=’nx_db’;
select count(1) from information_schema.views where table_schema=’nx_db’;
业务测通过创立测试表 / 增删改查等操作验证 ddl/dml 是否失常复制。
根底性能验证实现后，还需进一步验证源端数据库主从切换以及网络中断对数据库同步的影响，对源端数据库的日志配置，要提出 Binlog 本地保留时长需要（不少于 48 小时），防止网络中断工夫过长导致的日志过期 而影响数据库的同步业务。
为保障数据及业务灾备的可靠性，须要对网络专线做实时的监控及告警配置，当呈现网络问题时，须要能及时收到告警，第一工夫解决，防止两头专线网络中断对灾备业务的可用性的影响。
POC 验证期间已经对网络影响进行中断测试，中断 2 小时，后续察看数据仍能失常同步追平，可能容忍理论业务中可能呈现的网络中断造成的影响。
对源库的爱护
在这个异构云容灾的案例中，因为与源端云是通过专线做了网络互通，而源端的数据库是通过 IP 形式拜访的，因而，在利用主机整体迁徙到京东侧后，主机依然能够通过网络拜访到源端数据库，这样有可能对源端库的写操作，为阻断对源端数据库的拜访，能够采纳主机平安组形式，阻断主机对外部 3306 端口的拜访，或通过子网级别的 ACL，限度对指定网段的特定端口的拜访，在利用配置调整后，数据库连贯指向扭转后，再调整平安组条目或 ACL 策略，放开对应的拜访权限。
因局部数据库的子网布局问题，应用 ACL 可能对数据库同步造成影响，因而在此案例，为业务主机创立一个附加平安组，配置 3306 端口阻断策略，实现了对源端数据库的拜访爱护。待业务调整实现后，解除平安组，即可实现业务数据的失常写入。
二、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 的服务端口。
案例三
客户业务从友商云迁徙到京东云，源端 ES 为 K8S 集群自建服务，服务拜访形式为 nodeport 形式，因为平安起因，限度拜访形式为外部业务主机拜访，服务未通过互联网对外开放。
抉择迁徙技术计划，源端自建的 ES 未装置 S3 插件，思考到快照形式迁徙须要源端装置 S3 插件，而通过 POD 形式部署的业务须要从新制作镜像并更新利用，从工夫及工作量上思考不是最佳抉择，因而采取 reindex 形式来做业务数据的迁徙。
为实现从京东云侧对 ES 的数据拉取，在源端配置一个 nginx 反向代理，实现了通过公网对外部 ES 接口的拜访，同时配置白名单，限度拜访 IP 为京东侧 NAT 网关进口的公网 IP，确保数据的拜访平安。
在京东云侧，因生产环境子网未配置公网进口，为长期拉取数据，满足迁徙需要，调整路由表，配置明细路由，将源端公网 IP 配置到对应子网的路由表中，指向 NAT 网关，长期买通公网连贯，通过 NAT 网关能够拉取到源侧的 ES 数据，并在 ES 服务中对源端的公网 IP 做加白操作，留神加白操作会重启 ES 服务。
为满足网络通信需要，长期配置 ES 子网的明细路由，实现数据迁徙后需删除明细路由。
迁徙前，确认相干迁徙条件曾经具备：
- 源端及京东云 ES 服务均创立对应索引，须要确认云上索引是新建的，源端与目标端的 mapping 能够一样，也能够不同，通过 reindex，能够实现批改 mapping 后的字段类型。
- 能够从京东云侧 ES 拜访到源端云侧服务的 ES 的服务端口，验证形式，telnet 或 curl -XGET http://:9200 形式验证均可。
在源端创立索引 ：
源 ES 集群
1. 创立索引（示例）
2. 写入数据(示例)
指标端 ES 配置
三、对象存储的迁徙
对兼容 S3 协定的对象存储数据迁徙，各个私有云厂商（包含局部传统灾备厂商）均有迁徙工具或脚本，迁徙技术难度不高。然而，因为不同厂家的对象存储在不同 region 可能存在底层版本及配置差别。
因而，同一个工具或脚本，在解决不同区域的对象存储数据时，可能会呈现文件拜访问题，在做迁徙前后，须要对迁徙的数据做完整性和可用性校验。
对象存储迁徙的个别程序：
1、指标端配置镜像回源，保障读 404 能够回源拿到数据
2、应用迁徙工具迁徙源端的历史数据
3、同步后的数据校验
理论迁徙中，因为波及到增量数据的同步（迁徙工具反对对 transfer.coverFile 的参数设置，是否覆盖文件，因而也能够做到增量复制），因而，应依据我的项目理论的数据存储量、业务拜访个性、业务停机窗口等信息，综合思考迁徙流程和抉择技术计划。
案例四
某业务从友商云迁徙到京东云，波及到对象存储迁徙，源端文件数量约为 1000 万级别，迁徙前，先对源端对象存储做文件 list，查看迁徙工具 list 数据与对象存储理论数据可能匹配，而后通过迁徙工具做迁徙操作，因文件量较大，而且业务每天都有新数据上传，要保障所有文件都正确同步。因而采纳的的历史和增量数据同步计划为提前一周做全量迁徙，而后通过镜像回源同步新增文件。割接前一周做全量迁徙
1、在割接一周前，利用京东云的 osstransfer 迁徙工具进行全量迁徙。
2、迁徙后会生成一个以源 oss 的 bucket 命名的.list.txt 的文件，此文件里含用源 oss bucket 的所有文件的清单。
3、迁徙日志会生成在迁徙的工具包 log 目录下，相干 log 阐明（log 文件很重要，迁徙实现后做了一个异地备份）：迁徙的所有文件将记录在 audit-0.log 中
迁徙胜利的文件记录在 audit.success 中
能够用命令 grep“1$”audit-0.log 查看迁徙失败的文件
用生成的源 oss 的清单文件列表的 txt 文件中的文件数量和 audit.success 文件中的文件数量进行比照，如果数量统一阐明全副迁徙胜利。
文件 list 获取配置示例：
割接当天进行全量迁徙后的增量迁徙
1、利用 osstransfer 工具生成源 oss 的清单文件列表。
2、从文件列表清单中找出全量迁徙至增量迁徙这段时间内新减少的文件。
3、开启 oss 的镜像回源。
4、应用 curl 拜访新减少的文件(要拜访指标端 oss)，进行新增文件的镜像回源。
理论迁徙中遇到了问题：
在 POC 阶段，做测试环境数据迁徙时，采纳这个计划验证一切顺利，然而在生产环境割接时，遇到了问题，判断增量文件所需的 list 清单呈现循环谬误，导致 list 工作始终运行中，而 list 的清单有大量反复内容。
迁徙软件版本与测试环境迁徙应用的版本统一，而生产环境中，迁徙软件在一周前的全量同步的应用也是一切正常。数据也失常同步到了京东云的对象存储中，割接时须要的是通过回源形式获取一周内新增的文件，如果 list 文件不正确，会导致增量的数据同步无奈进行。
问题解决
业务割接工夫无限，迅速降级问题，将问题反馈到工具软件的研发共事，研发共事迅速投入排查（已是凌晨，为京东研发同学的敬业精神点个赞）。通过研发共事排查，发现源端的友商云上，测试环境应用的对象存储与生产环境的对象存储位于不同区域（zone），而友商云的生产环境对象存储所在区域的 OSS 接口在本周做了调整，导致原有工具 list 呈现谬误。
研发共事紧急更新一个工具包提供给迁徙现场共事，解决了对象存储文件 list 循环谬误问题，顺利完成了文件 list 查看，通过比照前后生成的 list 文件，获取到新增的文件列表。配置镜像回源，通过脚本同步了一周的新增文件，校验无误后，配置业务利用启用对象存储，业务启动及验证工作持续失常进行。
四、redis 迁徙
业务中 Redis 应用有两种场景，一种是仅作为缓存，不做数据长久化，这种业务场景，迁徙后在新环境部署业务后间接调整业务指向新的 redis 实例即可，一种是有数据长久化，这种业务在迁徙到云上时，须要依据业务需要，做 redis 数据的迁徙操作。
Redis 有 rdb（point-in-time snapshot）和 aof 两种长久化计划，其中 rdb 模式是二进制格局，相似于快照，复原间接笼罩，aof 保留的是命令（文本格式），相似于追加模式，如果须要保留指标端的 redis 的数据，能够应用 aof 形式，aof 形式须要把源端 redis 做停写操作。Redis 加载 RDB 复原数据速度快于 AOF 的形式，但要留神老版本 Redis 服务不兼容新版 RDB 格局，因而 RDB 模式不实用降级的迁徙或复原。
在业务迁徙时，须要依据 redis 的应用场景、源端与目标端版本要求，数据存储、网络条件等抉择实用的 redis 迁徙工具。
Rdb 及 aof 的迁徙，官网有具体的阐明（bgrewriteaof/bgsave/redisdump 等），应用也绝对简略，因而本文不多做介绍。
京东云研发了 redis 的迁徙工具 redissycner（目前反对自建 redis 业务迁徙），通过模仿 redis 的 replication 协定，提供 redis 迁徙及同步。
Redissycner 通过 docker 部署形式：
git clone https://github.com/TraceNatur…
进入目录 docker-compose up –d
下载客户端软件：wgethttps://github.com/TraceNatur… md64.tar.gz
调整配置文件：.config.yaml syncserver: http://x.x.x.x:8080（docker 服务地址）token: xxx
留神 token 文件内容须要在容器中确认。
编辑配置文件后即可启动服务，通过编写要执⾏的工作 json 来配置操作环境。
{
“sourcePassword”:“xxxx”,
“sourceRedisAddress”:“10.0.1.101:6379”,
“targetRedisAddress”:“10.0.1.102:6379”,
“targetPassword”:“xxxx”,
“taskName”:“testtask”,
“targetRedisVersion”: 4.0,
“autostart”: true,
“afresh”: true,
“batchSize”: 100
} redissyncer-cli -i
redissyncer-cli > task create source ./task.json
五、数据备份的重要性
数据备份是在业务迁徙的全生命周期怎么强调都不过分的环节（也包含迁徙后的一段期间），因数据备份不充沛导致数据失落、业务受损的教训很多，然而，在迁徙施行过程中，因漠视数据备份而导致呈现问题的事件依然很常见。
问题可能来自客户，可能来自咱们施行团队，也可能来自 ISV 或者其余可能操作数据的团队或集体。有些问题是因为迁徙各个责任方的沟通不充沛、宣贯不到位或技术不过关导致，有些是误操作导致。
理论场景中数据备份施行的压力或阻力，次要来自存储空间有余以及备份过程可能造成的对性能的影响。
除了备份的数据文件须要占用存储空间，数据库文件的可用性、一致性验证，同样会占用大量的存储空间（长期），因而在理论迁徙过程中，对存储空间的需要，可能会大于现有数据库的数据量的 2 倍（源端及指标端都是如此）。因而，在重要业务场景中，迁徙前，须要对数据备份所需的存储空间做好评估并思考备份空间的老本。
案例五
某局委办业务由 vmware 环境迁徙到政务云，在迁徙前，笔者为客户做了所有迁徙主机的整机备份（导出到 vmware 内部的内部存储中），事实证明这些环节（筹备存储环境、沟通 vmware 运维方、数据导出耗时等）导致的成本增加是值得的。
迁徙过程很顺利，在业务迁徙到政务云失常服务实现业务交接大概 1 个月后，接到客户电话，心愿可能通过迁徙前备份的主机复原数据。
问题起因
起因是一个 ISV 在新环境做业务降级时，安顿了一个没有教训的新人，把数据库软件做了重新安装，并删除了原有数据。在帮助客户通过备份的镜像复原数据后（历史数据，新增数据局部由 ISV 做了增补操作），客户购买了政务云提供的灾备服务，开始定期对重要主机和数据做全量及增量备份，通过云上的容灾服务来防止或缩小业务谬误或误操作造成的损失。
六、业务数据迁徙总结
1、提前做好备份，有了备份数据，迁徙过程的压力会减小，绝对宽松的迁徙气氛对迁徙施行很无利。
2、迁徙技术及工具的抉择，当初数据迁徙工具越来越多，各个大厂也都有本人的工具，然而产品的限度及兼容水平各有不同，须要依据业务性质抉择并验证。
3、筹备回退预案，做好 POC 验证，POC 能发现局部问题，提前准备解决方案。
4、做好流程手册，明确操作责任人，分割相干部门做好迁徙的切换阶段的护航筹备。产品和服务类的问题肯定要能找到人反对。
5、明确责任矩阵、进行全面沟通，沟通可能发现技术层面很难发现的问题，越早建设迁徙组织并造成无限的沟通机制，对迁徙的顺利施行越无利。
