前言

在支撑京东集团内部及京东云外部客户的事务搬迁到京东公有云及京东私有云、京东政务云的进程中，技能服务组积累了相关事务体系数据搬迁的一些办理和技能经历，以事例的办法分享给咱们，期望对咱们的事务搬迁作业有所帮忙。

搬迁前的预备作业

事务搬迁上云触及到的事务数据品种繁多，主要类型包括：

数据库：联络型数据库 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 TableDDL操作，不同厂家的东西约束条件或许不同，需求仔细阅读产品阐明，并经过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.创立索引（示例）
PUT 11_index_11
{
“mappings”:
{
“user”:{
“properties”:{
“name”:{“type”:”text”},
“title”:{“type”:”text”},
“age”:{“type”:”integer”}
}
}
}
}

2.写入数据(示例)
POST 11_index_11/user
{
“title”:”manager”,
“name”:”XP”,
“age”:22
}

方针端ES装备

1.创立索引（示例）

PUT 11_index_11
{
“mappings”:
{
“user”:{
“properties”:{
“name”:{“type”:”text”},
“title”:{“type”:”text”},
“age”:{“type”:”integer”}
}
}
}
}

2、装备 reindex.remote.whitelist 参数，指明可以reindex 的长途集群的白名单，并重启方针端集群服务。

业务数据迁移上云的一些技术思考 | 京东云技术团队

3 、reindex搬迁数据

POST _reindex（示例）
{
“source”: {
“remote”: {
“host”: “http://sourceIP:9200“,
“socket_timeout”: “1m”,
“connect_timeout”: “10s”
},
“index”: “11_index_11”
},
“dest”: {
“index”: “11_index_11”
}
}
搬迁后，做数据校验，完结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 clonegithub.com/TraceNature…
进入目录docker-compose up –d
下载客户端软件：wgetgithub.com/TraceNature…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、清晰责任矩阵、进行全面交流，交流可以发现技能层面很难发现的问题，越早建立搬迁安排并形成有限的交流机制，对搬迁的顺利施行越有利。

作者：京东科技 张久志

来源：京东云开发者社区