業(yè)務(wù)數(shù)據(jù)遷移上云的一些技術(shù)思考

作者：京東云開發(fā)者 2022-08-23 09:36:25

提前做好備份，有了備份數(shù)據(jù)，遷移過程的壓力會(huì)減小，相對(duì)寬松的遷移氛圍對(duì)遷移實(shí)施很有利。

前言

在支持京東集團(tuán)內(nèi)部及京東云外部客戶的業(yè)務(wù)遷移到京東公有云及京東私有云、京東政務(wù)云的過程中，京東科技-京東云事業(yè)群-技術(shù)服務(wù)組積累了相關(guān)業(yè)務(wù)系統(tǒng)數(shù)據(jù)遷移的一些管理和技術(shù)經(jīng)驗(yàn)，以案例的形式分享給大家，希望對(duì)大家的業(yè)務(wù)遷移工作有所幫助。

遷移前的準(zhǔn)備工作

業(yè)務(wù)遷移上云涉及到的業(yè)務(wù)數(shù)據(jù)種類繁多，主要類型包括：

數(shù)據(jù)庫：

關(guān)系型數(shù)據(jù)庫 MySQL 、PG、Oracle等

對(duì)象存儲(chǔ)：

標(biāo)準(zhǔn)S3接口對(duì)象存儲(chǔ)遷移中間件數(shù)據(jù)：ES、mongoDB、redis等

文件存儲(chǔ)：

文檔、圖片等非結(jié)構(gòu)化數(shù)據(jù)

大數(shù)據(jù)：

HBASE、HDFS files等

京東云的內(nèi)外部客戶在上云過程中，大部分業(yè)務(wù)均涉及到以上多種數(shù)據(jù)類型，基于相關(guān)遷移的案例所積累的經(jīng)驗(yàn)，數(shù)據(jù)遷移需要在遷移啟動(dòng)前至少做好如下準(zhǔn)備工作。

1、可執(zhí)行的數(shù)據(jù)遷移技術(shù)方案制定完成，包含明確的遷移操作步驟（遷移前準(zhǔn)備工作，遷移操作、遷移后校驗(yàn)工作）、執(zhí)行人、確認(rèn)人。

2、制定遷移應(yīng)急預(yù)案及回切方案，明確責(zé)任矩陣，確認(rèn)異常情況的決策條件及決策人。

3、確認(rèn)數(shù)據(jù)安全等級(jí)，確認(rèn)數(shù)據(jù)遷移的方案合規(guī)安全，通過相關(guān)業(yè)務(wù)安全部門審核。

4、遷移時(shí)長(zhǎng)及割接數(shù)據(jù)同步窗口的評(píng)估（以POC驗(yàn)證數(shù)據(jù)信息為基礎(chǔ)制定），確認(rèn)各個(gè)業(yè)務(wù)及數(shù)據(jù)遷移可選的第二方案。

5、確認(rèn)網(wǎng)絡(luò)帶寬及質(zhì)量滿足遷移需求。

案例分析

下面是幾個(gè)案例，涉及到了不同數(shù)據(jù)遷移的場(chǎng)景。

一、關(guān)系型數(shù)據(jù)庫

MySQL：

MySQL在遷移中最為常見，也有很成熟的遷移工具和遷移方案，包括官方工具和相關(guān)開源工具，如mysqldump等，各個(gè)云廠商也都有各自的DTS遷移工具。

DTS工具：

DTS服務(wù)在傳輸及同步、數(shù)據(jù)校驗(yàn)等步驟都實(shí)現(xiàn)了一定的抽象化，具有相對(duì)友好的交互界面，同時(shí)可以實(shí)現(xiàn)多個(gè)任務(wù)并行進(jìn)行，對(duì)要求平滑遷移的場(chǎng)景，具有自動(dòng)化優(yōu)勢(shì)，節(jié)省大量人力，有部分DTS工具可以實(shí)現(xiàn)跨版本遷移。

DTS的限制是：

（1）源端數(shù)據(jù)庫與目標(biāo)端數(shù)據(jù)庫與DTS管理服務(wù)IP網(wǎng)絡(luò)互通，并具備穩(wěn)定的網(wǎng)絡(luò)連接。

（2）數(shù)據(jù)庫需要滿足一定的前提條件才能實(shí)現(xiàn)遷移后的增量同步功能，通常的需求是權(quán)限需求，比如REPLICATION SLAVE,REPLICATION等，同時(shí)存儲(chǔ)過程及函數(shù)在全量+增量的場(chǎng)景下不會(huì)被包含，在全量遷移階段，不支持 Alter Table、Drop Table DDL 操作，**不同廠家的工具限制條件可能不同，需要仔細(xì)閱讀產(chǎn)品說明，并通過POC驗(yàn)證功能。

mysqldump工具：

適合的場(chǎng)景，數(shù)據(jù)庫源端與目的端沒有良好網(wǎng)絡(luò)連接或無網(wǎng)絡(luò)連接的情況下，允許有一定的業(yè)務(wù)中斷時(shí)間，則在停機(jī)窗口完成數(shù)據(jù)導(dǎo)出、導(dǎo)入是比較適合的方案（如果具有主機(jī)級(jí)別的管理和控制能力，直接將數(shù)據(jù)庫主機(jī)整體以鏡像方式遷移也是一個(gè)可行的遷移方法）。

Mysqldump導(dǎo)出導(dǎo)入速度相對(duì)DTS要快（本地操作，而且與DTS相比，少了一些中間環(huán)節(jié)），但是多了一個(gè)數(shù)據(jù)文件壓縮及通過網(wǎng)絡(luò)或移動(dòng)介質(zhì)傳送的時(shí)間。

其他開源及商業(yè)工具，如streamset等，可以支持mysql到異構(gòu)數(shù)據(jù)庫的同步，功能比較強(qiáng)大，同時(shí)限制也比較多。

遷移時(shí)長(zhǎng)的估算：

業(yè)務(wù)割接過程中，業(yè)務(wù)數(shù)據(jù)的遷移及同步是切換前的重要步驟，也是割接過程中耗時(shí)較長(zhǎng)，容易出現(xiàn)錯(cuò)誤并導(dǎo)致割接延時(shí)或失敗的環(huán)節(jié)，因此要對(duì)數(shù)據(jù)遷移及同步耗時(shí)做出靠譜的估算。

數(shù)據(jù)庫同步，是表級(jí)別的并發(fā)來遷移全量數(shù)據(jù)，因此，DTS得結(jié)合實(shí)際的數(shù)據(jù)類型、數(shù)據(jù)行數(shù)、網(wǎng)絡(luò)帶寬、網(wǎng)絡(luò)延遲、同步實(shí)例規(guī)格，庫表的數(shù)量、單庫表的大小等因素評(píng)估時(shí)長(zhǎng)。

舉例來說，數(shù)據(jù)庫大小 500G，有5張表，其中一個(gè)單表400G，剩下4張表各25G，因單表400G相對(duì)較大，遷移時(shí)長(zhǎng)會(huì)拉長(zhǎng)。如果是5個(gè)100G的表，遷移時(shí)長(zhǎng)會(huì)縮減。

在正式遷移生產(chǎn)數(shù)據(jù)前，一般會(huì)有對(duì)測(cè)試環(huán)境的遷移POC，來驗(yàn)證和評(píng)估生產(chǎn)環(huán)境的切換流程及耗時(shí)，制定生產(chǎn)業(yè)務(wù)割接的計(jì)劃時(shí)，要以這個(gè)時(shí)間為數(shù)據(jù)庫遷移的時(shí)長(zhǎng)依據(jù)。

京東云DTS數(shù)據(jù)遷移同步架構(gòu)如下圖：

案例一

從友商公有云遷移到京東公有云云，由于源端binlog問題導(dǎo)致的一次DTS遷移到手動(dòng)遷移方式的轉(zhuǎn)換。

項(xiàng)目條件，業(yè)務(wù)具有8小時(shí)的停服時(shí)間，因此在遷移技術(shù)方案DTS及手動(dòng)導(dǎo)數(shù)據(jù)庫都是可選方案，鑒于DTS的不停服及數(shù)據(jù)增量功能特性，我們選擇在停服前開始通過京東云DTS服務(wù)同步歷史數(shù)據(jù)，并開啟DTS增量同步功能，基于停機(jī)窗口，我們給數(shù)據(jù)庫在線遷移及增量同步的時(shí)間為4小時(shí)，DTS服務(wù)不影響在線業(yè)務(wù)，基于測(cè)試環(huán)境的遷移經(jīng)驗(yàn)及評(píng)估。

在停服前的下午，為了給遷移留出足夠的時(shí)間緩沖，我們提前啟動(dòng)了主數(shù)據(jù)庫的DTS服務(wù)，數(shù)據(jù)庫遷移進(jìn)程正常進(jìn)行，預(yù)計(jì)遷移時(shí)長(zhǎng)為4小時(shí)，但是在DTS服務(wù)最后階段，因源端binlog問題，出現(xiàn)了一個(gè)致命錯(cuò)誤，導(dǎo)致DTS任務(wù)失敗。

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.

因?yàn)樽罱Kbinlog錯(cuò)誤（部分binglog丟失），DTS任務(wù)無法恢復(fù)，最終DTS傳輸?shù)?小時(shí)時(shí)間被浪費(fèi)，因遷移是系統(tǒng)工程，其他數(shù)據(jù)遷移進(jìn)程也都在根據(jù)計(jì)劃推進(jìn)，此時(shí)大家都沒有時(shí)間去分析具體原因。

因到晚上客戶業(yè)務(wù)已經(jīng)推送通知并停服，此時(shí)業(yè)務(wù)遷移的其他數(shù)據(jù)遷移及業(yè)務(wù)調(diào)試已經(jīng)開始。

所以，當(dāng)機(jī)立斷決定以mysqldump模式導(dǎo)出文件，本地導(dǎo)出速度很快（20M/s），壓縮后的數(shù)據(jù)庫導(dǎo)出文件體積縮小，減少了網(wǎng)絡(luò)傳輸耗時(shí)。通過網(wǎng)絡(luò)傳輸?shù)骄〇|云側(cè)的云主機(jī)，然后source方式導(dǎo)入RDS。導(dǎo)出、傳輸、導(dǎo)入整個(gè)過程耗時(shí)小于2小時(shí)。

導(dǎo)入MySQL數(shù)據(jù)后，根據(jù)遷移流程做遷移數(shù)據(jù)校驗(yàn)，使用checksum_table工具對(duì)源端和目的端數(shù)據(jù)庫做對(duì)比。

源庫信息：—src-host sourceIP —src-user user —src-pass pass

目標(biāo)庫信息：—dest-host targetURL —dest-user user —dest-pass pass

驗(yàn)證過程中，發(fā)現(xiàn)部分表不一致，與業(yè)務(wù)方確認(rèn)為源端在遷移開始后，停止服務(wù)不徹底導(dǎo)致，仍然有數(shù)據(jù)寫入操作，因?yàn)闃I(yè)務(wù)側(cè)并沒有根據(jù)遷移規(guī)范檢查mq、kafka的消息產(chǎn)生情況，只是停止了部分服務(wù)，后經(jīng)業(yè)務(wù)及研發(fā)檢查新增數(shù)據(jù)，對(duì)部分?jǐn)?shù)據(jù)做清理后，完成數(shù)據(jù)庫的遷移工作。

根據(jù)項(xiàng)目經(jīng)驗(yàn)，這種DTS服務(wù)因binlog問題導(dǎo)致的失敗情況并非個(gè)案。

準(zhǔn)備工作

（1）為數(shù)據(jù)庫遷移準(zhǔn)備一個(gè)備選方案并準(zhǔn)備好應(yīng)急預(yù)案。

（2）出現(xiàn)問題時(shí)，決策條件及決策人提前確認(rèn)，在實(shí)施過程中能根據(jù)需要及時(shí)決策做出調(diào)整。

廠商改良（非原生）的數(shù)據(jù)庫的遷移：

在某些云廠商的特定數(shù)據(jù)庫版本中，會(huì)對(duì)標(biāo)準(zhǔn)的數(shù)據(jù)庫產(chǎn)品如mariaDB、PG等數(shù)據(jù)庫做一些定制化的開發(fā)，以滿足客戶的業(yè)務(wù)的某些特殊需求，這種數(shù)據(jù)庫屬于廠家深度綁定的類型，在做業(yè)務(wù)遷移或?yàn)?zāi)備數(shù)據(jù)同步的時(shí)候，根據(jù)時(shí)間場(chǎng)景做定制化的遷移及同步方案，大部分需要從研發(fā)層面做一些定制化的配置和操作。

案例二

某金融用戶，原系統(tǒng)運(yùn)行于T的金融云，使用了定制化的RDS服務(wù)，因金融行業(yè)的業(yè)務(wù)及數(shù)據(jù)災(zāi)備規(guī)范，需要做異地容災(zāi)，目標(biāo)為實(shí)現(xiàn)業(yè)務(wù)級(jí)別災(zāi)備，將災(zāi)備系統(tǒng)運(yùn)行于京東金融云平臺(tái)。

為實(shí)現(xiàn)從T云定制化的TDSQL到京東云的遷移，對(duì)源端的數(shù)據(jù)庫做了詳細(xì)調(diào)研，因?yàn)樵炊耸嵌ㄖ苹摹⒕哂凶詣?dòng)水平拆分、Shared Nothing 架構(gòu)的分布式數(shù)據(jù)庫，因此使用京東云的DTS工具不適用于這個(gè)場(chǎng)景，同時(shí)，在兩個(gè)環(huán)境，要求數(shù)據(jù)基本為實(shí)時(shí)同步才能滿足業(yè)務(wù)容災(zāi)的需求。

制定方案

在制定數(shù)據(jù)同步方案時(shí)，也對(duì)傳統(tǒng)災(zāi)備廠商的方案做了調(diào)研，因傳統(tǒng)廠商災(zāi)備方案多以主機(jī)級(jí)別數(shù)據(jù)及IO分析或日志分析為基礎(chǔ)，需要做一些侵入式agent的安裝，與云上RDS的場(chǎng)景無法適配，相關(guān)廠商也表示正在做向云上災(zāi)備的轉(zhuǎn)型，但尚未有成熟落地的產(chǎn)品（適配難度較大），因此最終方案采取了基于gtid的主從復(fù)制的方案來實(shí)現(xiàn)數(shù)據(jù)庫的異構(gòu)云同步，屏蔽了架構(gòu)差異帶來的問題。

注意：涉及業(yè)務(wù)信息及底層操作的部分內(nèi)容已經(jīng)隱去。

首先對(duì)源端做權(quán)限調(diào)整：
GRANT SELECT, RELOAD, SHOW DATABASES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, SHOW VIEW ON . TO ‘user’@’192.168.%’
對(duì)源端做全量的邏輯備份：
mysqldump –h xx –uusername -p –database nx_db -f —single-transaction —master-data=2 —skip-lock-tables > /data1/bs.dmp
注意導(dǎo)出文件中要有g(shù)tid信息。
災(zāi)備端導(dǎo)入：
mysql –h xx -f –uusername -p < bs.dmp
后臺(tái)做復(fù)制配置：
set gtid_slave_pos=’0-13381-1xxxx06’;
CHANGE MASTER TO MASTER_HOST=’sourceIP’,MASTER_USER=’username’,MASTER_PASSWORD=’*‘,MASTER_USE_GTID=’slave_pos’;
同步驗(yàn)證
數(shù)據(jù)驗(yàn)證
（1）業(yè)務(wù)側(cè)停止寫操作，在T云側(cè)和京東云側(cè)分別通過checksum table tablename對(duì)關(guān)鍵表做校驗(yàn)。
（2）業(yè)務(wù)側(cè)在T云/京東云兩邊分別執(zhí)行命令，對(duì)表/view等做數(shù)量校驗(yàn)：
select count(1) from information_schema.tables where table_schema=’nx_db’;
select count(1) from information_schema.views where table_schema=’nx_db’;
業(yè)務(wù)測(cè)通過創(chuàng)建測(cè)試表/增刪改查等操作驗(yàn)證ddl/dml是否正常復(fù)制。

基礎(chǔ)功能驗(yàn)證完成后，還需進(jìn)一步驗(yàn)證源端數(shù)據(jù)庫主從切換以及網(wǎng)絡(luò)中斷對(duì)數(shù)據(jù)庫同步的影響，對(duì)源端數(shù)據(jù)庫的日志配置，要提出Binlog本地保留時(shí)長(zhǎng)需求（不少于48小時(shí)），避免網(wǎng)絡(luò)中斷時(shí)間過長(zhǎng)導(dǎo)致的日志過期而影響數(shù)據(jù)庫的同步業(yè)務(wù)。

為保障數(shù)據(jù)及業(yè)務(wù)災(zāi)備的可靠性，需要對(duì)網(wǎng)絡(luò)專線做實(shí)時(shí)的監(jiān)控及告警配置，當(dāng)出現(xiàn)網(wǎng)絡(luò)問題時(shí)，需要能及時(shí)收到告警，第一時(shí)間處理，避免中間專線網(wǎng)絡(luò)中斷對(duì)災(zāi)備業(yè)務(wù)的可用性的影響。

POC驗(yàn)證期間曾經(jīng)對(duì)網(wǎng)絡(luò)影響進(jìn)行中斷測(cè)試，中斷2小時(shí)，后續(xù)觀察數(shù)據(jù)仍能正常同步追平，能夠容忍實(shí)際業(yè)務(wù)中可能出現(xiàn)的網(wǎng)絡(luò)中斷造成的影響。

對(duì)源庫的保護(hù)

在這個(gè)異構(gòu)云容災(zāi)的案例中，因?yàn)榕c源端云是通過專線做了網(wǎng)絡(luò)互通，而源端的數(shù)據(jù)庫是通過IP方式訪問的，因此，在應(yīng)用主機(jī)整體遷移到京東側(cè)后，主機(jī)仍然可以通過網(wǎng)絡(luò)訪問到源端數(shù)據(jù)庫，這樣有可能對(duì)源端庫的寫操作，為阻斷對(duì)源端數(shù)據(jù)庫的訪問，可以采用主機(jī)安全組方式，阻斷主機(jī)對(duì)外部3306端口的訪問，或通過子網(wǎng)級(jí)別的ACL，限制對(duì)指定網(wǎng)段的特定端口的訪問，在應(yīng)用配置調(diào)整后，數(shù)據(jù)庫連接指向改變后，再調(diào)整安全組條目或ACL策略，放開對(duì)應(yīng)的訪問權(quán)限。

因部分?jǐn)?shù)據(jù)庫的子網(wǎng)規(guī)劃問題，使用ACL可能對(duì)數(shù)據(jù)庫同步造成影響，因此在此案例，為業(yè)務(wù)主機(jī)創(chuàng)建一個(gè)附加安全組，配置3306端口阻斷策略，實(shí)現(xiàn)了對(duì)源端數(shù)據(jù)庫的訪問保護(hù)。待業(yè)務(wù)調(diào)整完成后，解除安全組，即可實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)的正常寫入。

二、ES遷移

ES應(yīng)用越來越廣泛，業(yè)務(wù)遷移中，ES數(shù)據(jù)遷移已經(jīng)成為數(shù)據(jù)遷移的一個(gè)重要部分。

ES遷移技術(shù)涉及停服遷移及不停服遷移，不停服遷移對(duì)遷移的源端和目的端網(wǎng)絡(luò)及服務(wù)有很多要求，目前實(shí)現(xiàn)起來尚有很多限制，目前一般只在集團(tuán)內(nèi)部業(yè)務(wù)做ES不停服遷移。

通常停服遷移技術(shù)路徑可選擇reindex或snapshot方式及l(fā)ogstash方式，幾種方式均要參考官方對(duì)版本的要求，選擇滿足版本要求的遷移方式。

Snapshot方式：

Snapshot方式，從源ES集群創(chuàng)建數(shù)據(jù)快照，然后在目標(biāo)ES集群中進(jìn)行恢復(fù)。創(chuàng)建快照前必須先創(chuàng)建repository倉庫，一個(gè)repository倉庫可以包含多份快照文件。repository支持S3及共享文件存儲(chǔ)系統(tǒng)等，自建的ES可以使用共享文件存儲(chǔ)（從速度、成本等因素考慮，是最佳選擇），使用公有云ES服務(wù)的建議采用支持S3協(xié)議的對(duì)象存儲(chǔ)。

從速度和效率上來講，快照方式優(yōu)于reindex，當(dāng)不需要對(duì)源端做任何變更，且網(wǎng)絡(luò)存儲(chǔ)條件具備時(shí)，優(yōu)先選擇快照方式遷移ES。

reindex是Elasticsearch提供的一個(gè)api接口，可以把數(shù)據(jù)從源ES集群導(dǎo)入到當(dāng)前的ES集群，實(shí)現(xiàn)數(shù)據(jù)的遷移，reindex適用于數(shù)據(jù)量較大，有索引調(diào)整需求或無法連接共享存儲(chǔ)的遷移場(chǎng)景，以及只需要遷移部分?jǐn)?shù)據(jù)的場(chǎng)景。

reindex方式需要目標(biāo)端能夠訪問到源端ES的服務(wù)端口。

案例三

客戶業(yè)務(wù)從友商云遷移到京東云，源端ES為K8S集群自建服務(wù)，服務(wù)訪問方式為nodeport方式，因?yàn)榘踩颍拗圃L問方式為內(nèi)部業(yè)務(wù)主機(jī)訪問，服務(wù)未通過互聯(lián)網(wǎng)對(duì)外開放。

選擇遷移技術(shù)方案，源端自建的ES未安裝S3插件，考慮到快照方式遷移需要源端安裝S3插件，而通過POD方式部署的業(yè)務(wù)需要重新制作鏡像并更新應(yīng)用，從時(shí)間及工作量上考慮不是最佳選擇，因此采取reindex方式來做業(yè)務(wù)數(shù)據(jù)的遷移。

為實(shí)現(xiàn)從京東云側(cè)對(duì)ES的數(shù)據(jù)拉取，在源端配置一個(gè)nginx反向代理，實(shí)現(xiàn)了通過公網(wǎng)對(duì)內(nèi)部ES接口的訪問，同時(shí)配置白名單，限制訪問IP為京東側(cè)NAT網(wǎng)關(guān)出口的公網(wǎng)IP，確保數(shù)據(jù)的訪問安全。

在京東云側(cè)，因生產(chǎn)環(huán)境子網(wǎng)未配置公網(wǎng)出口，為臨時(shí)拉取數(shù)據(jù)，滿足遷移需求，調(diào)整路由表，配置明細(xì)路由，將源端公網(wǎng)IP配置到對(duì)應(yīng)子網(wǎng)的路由表中，指向NAT網(wǎng)關(guān)，臨時(shí)打通公網(wǎng)連接，通過NAT網(wǎng)關(guān)可以拉取到源側(cè)的ES數(shù)據(jù)，并在ES服務(wù)中對(duì)源端的公網(wǎng)IP做加白操作，注意加白操作會(huì)重啟ES服務(wù)。

為滿足網(wǎng)絡(luò)通信需求，臨時(shí)配置ES子網(wǎng)的明細(xì)路由，完成數(shù)據(jù)遷移后需刪除明細(xì)路由。

遷移前，確認(rèn)相關(guān)遷移條件已經(jīng)具備：

源端及京東云ES服務(wù)均創(chuàng)建對(duì)應(yīng)索引，需要確認(rèn)云上索引是新建的，源端與目的端的mapping可以一樣，也可以不同，通過reindex，可以實(shí)現(xiàn)修改mapping后的字段類型。
可以從京東云側(cè)ES訪問到源端云側(cè)服務(wù)的ES的服務(wù)端口，驗(yàn)證方式，telnet或curl -XGET??http://:9200??方式驗(yàn)證均可。

在源端創(chuàng)建索引：

源ES集群

1.創(chuàng)建索引（示例）

2.寫入數(shù)據(jù)(示例)

目標(biāo)端ES配置

三、對(duì)象存儲(chǔ)的遷移

對(duì)兼容S3協(xié)議的對(duì)象存儲(chǔ)數(shù)據(jù)遷移，各個(gè)公有云廠商（包括部分傳統(tǒng)災(zāi)備廠商）均有遷移工具或腳本，遷移技術(shù)難度不高。但是，因?yàn)椴煌瑥S家的對(duì)象存儲(chǔ)在不同region可能存在底層版本及配置差異。

因此，同一個(gè)工具或腳本，在處理不同區(qū)域的對(duì)象存儲(chǔ)數(shù)據(jù)時(shí)，可能會(huì)出現(xiàn)文件訪問問題，在做遷移前后，需要對(duì)遷移的數(shù)據(jù)做完整性和可用性校驗(yàn)。

對(duì)象存儲(chǔ)遷移的一般順序：

1、目標(biāo)端配置鏡像回源，保證讀404可以回源拿到數(shù)據(jù)

2、使用遷移工具遷移源端的歷史數(shù)據(jù)

3、同步后的數(shù)據(jù)校驗(yàn)

實(shí)際遷移中，因?yàn)樯婕暗皆隽繑?shù)據(jù)的同步（遷移工具支持對(duì)transfer.coverFile的參數(shù)設(shè)置，是否覆蓋文件，因此也可以做到增量復(fù)制），因此，應(yīng)根據(jù)項(xiàng)目實(shí)際的數(shù)據(jù)存儲(chǔ)量、業(yè)務(wù)訪問特性、業(yè)務(wù)停機(jī)窗口等信息，綜合考慮遷移流程和選擇技術(shù)方案。

案例四

某業(yè)務(wù)從友商云遷移到京東云，涉及到對(duì)象存儲(chǔ)遷移，源端文件數(shù)量約為1000萬級(jí)別，遷移前，先對(duì)源端對(duì)象存儲(chǔ)做文件list，檢查遷移工具list數(shù)據(jù)與對(duì)象存儲(chǔ)實(shí)際數(shù)據(jù)能夠匹配，然后通過遷移工具做遷移操作，因文件量較大，而且業(yè)務(wù)每天都有新數(shù)據(jù)上傳，要保證所有文件都正確同步。因此采用的的歷史和增量數(shù)據(jù)同步方案為提前一周做全量遷移，然后通過鏡像回源同步新增文件。割接前一周做全量遷移

1、在割接一周前，利用京東云的osstransfer遷移工具進(jìn)行全量遷移。

2、遷移后會(huì)生成一個(gè)以源oss的bucket命名的.list.txt的文件，此文件里含用源oss bucket的所有文件的清單。

3、遷移日志會(huì)生成在遷移的工具包log目錄下，相關(guān)log說明（log文件很重要，遷移完成后做了一個(gè)異地備份）：遷移的所有文件將記錄在audit-0.log中

遷移成功的文件記錄在audit.success中

可以用命令grep “1$” audit-0.log查看遷移失敗的文件

用生成的源oss的清單文件列表的txt文件中的文件數(shù)量和audit.success文件中的文件數(shù)量進(jìn)行對(duì)比，如果數(shù)量一致說明全部遷移成功。

文件list獲取配置示例：

割接當(dāng)天進(jìn)行全量遷移后的增量遷移

1、利用osstransfer工具生成源oss的清單文件列表。

2、從文件列表清單中找出全量遷移至增量遷移這段時(shí)間內(nèi)新增加的文件。

3、開啟oss的鏡像回源。

4、使用curl訪問新增加的文件(要訪問目標(biāo)端oss)，進(jìn)行新增文件的鏡像回源。

實(shí)際遷移中遇到了問題：

在POC階段，做測(cè)試環(huán)境數(shù)據(jù)遷移時(shí)，采用這個(gè)方案驗(yàn)證一切順利，但是在生產(chǎn)環(huán)境割接時(shí)，遇到了問題，判斷增量文件所需的list清單出現(xiàn)循環(huán)錯(cuò)誤，導(dǎo)致list任務(wù)一直運(yùn)行中，而list的清單有大量重復(fù)內(nèi)容。

遷移軟件版本與測(cè)試環(huán)境遷移使用的版本一致，而生產(chǎn)環(huán)境中，遷移軟件在一周前的全量同步的使用也是一切正常。數(shù)據(jù)也正常同步到了京東云的對(duì)象存儲(chǔ)中，割接時(shí)需要的是通過回源方式獲取一周內(nèi)新增的文件，如果list文件不正確，會(huì)導(dǎo)致增量的數(shù)據(jù)同步無法進(jìn)行。

問題處理

業(yè)務(wù)割接時(shí)間有限，迅速升級(jí)問題，將問題反饋到工具軟件的研發(fā)同事，研發(fā)同事迅速投入排查（已是凌晨，為京東研發(fā)同學(xué)的敬業(yè)精神點(diǎn)個(gè)贊）。經(jīng)過研發(fā)同事排查，發(fā)現(xiàn)源端的友商云上，測(cè)試環(huán)境使用的對(duì)象存儲(chǔ)與生產(chǎn)環(huán)境的對(duì)象存儲(chǔ)位于不同區(qū)域（zone），而友商云的生產(chǎn)環(huán)境對(duì)象存儲(chǔ)所在區(qū)域的OSS接口在本周做了調(diào)整，導(dǎo)致原有工具list出現(xiàn)錯(cuò)誤。

研發(fā)同事緊急更新一個(gè)工具包提供給遷移現(xiàn)場(chǎng)同事，解決了對(duì)象存儲(chǔ)文件list循環(huán)錯(cuò)誤問題，順利完成了文件list檢查，通過對(duì)比前后生成的list文件，獲取到新增的文件列表。配置鏡像回源，通過腳本同步了一周的新增文件，校驗(yàn)無誤后，配置業(yè)務(wù)應(yīng)用啟用對(duì)象存儲(chǔ)，業(yè)務(wù)啟動(dòng)及驗(yàn)證工作繼續(xù)正常進(jìn)行。

四、redis遷移

業(yè)務(wù)中Redis使用有兩種場(chǎng)景，一種是僅作為緩存，不做數(shù)據(jù)持久化，這種業(yè)務(wù)場(chǎng)景，遷移后在新環(huán)境部署業(yè)務(wù)后直接調(diào)整業(yè)務(wù)指向新的redis實(shí)例即可，一種是有數(shù)據(jù)持久化，這種業(yè)務(wù)在遷移到云上時(shí)，需要根據(jù)業(yè)務(wù)需求，做redis數(shù)據(jù)的遷移操作。

Redis有rdb（point-in-time snapshot）和aof兩種持久化方案，其中rdb模式是二進(jìn)制格式，類似于快照，恢復(fù)直接覆蓋，aof保存的是命令（文本格式），類似于追加模式，如果需要保留目標(biāo)端的redis的數(shù)據(jù)，可以使用aof方式，aof方式需要把源端redis做停寫操作。Redis加載RDB恢復(fù)數(shù)據(jù)速度快于AOF的方式，但要注意老版本Redis服務(wù)不兼容新版RDB格式，因此RDB模式不適用降級(jí)的遷移或恢復(fù)。

在業(yè)務(wù)遷移時(shí)，需要根據(jù)redis的使用場(chǎng)景、源端與目的端版本要求，數(shù)據(jù)存儲(chǔ)、網(wǎng)絡(luò)條件等選擇適用的redis遷移工具。

Rdb及aof的遷移，官方有詳細(xì)的說明（bgrewriteaof/bgsave/redisdump等），使用也相對(duì)簡(jiǎn)單，因此本文不多做介紹。

京東云研發(fā)了redis的遷移工具redissycner（目前支持自建redis業(yè)務(wù)遷移），通過模擬redis的replication協(xié)議，提供redis遷移及同步。

Redissycner通過docker部署方式：

git clone https://github.com/TraceNatur...

進(jìn)入目錄docker-compose up –d

下載客戶端軟件：wgethttps://github.com/TraceNatur... md?64.tar.gz

調(diào)整配置文件：.config.yaml syncserver: http://x.x.x.x:8080 （docker服務(wù)地址） token: xxx

注意token文件內(nèi)容需要在容器中確認(rèn)。

編輯配置文件后即可啟動(dòng)服務(wù)，通過編寫要執(zhí)?的任務(wù)json來配置操作環(huán)境。

{
“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

五、數(shù)據(jù)備份的重要性

數(shù)據(jù)備份是在業(yè)務(wù)遷移的全生命周期怎么強(qiáng)調(diào)都不過分的環(huán)節(jié)（也包括遷移后的一段時(shí)期），因數(shù)據(jù)備份不充分導(dǎo)致數(shù)據(jù)丟失、業(yè)務(wù)受損的教訓(xùn)很多，但是，在遷移實(shí)施過程中，因忽視數(shù)據(jù)備份而導(dǎo)致出現(xiàn)問題的事件仍然很常見。

問題可能來自客戶，可能來自我們實(shí)施團(tuán)隊(duì)，也可能來自ISV或者其他可能操作數(shù)據(jù)的團(tuán)隊(duì)或個(gè)人。有些問題是因?yàn)檫w移各個(gè)責(zé)任方的溝通不充分、宣貫不到位或技術(shù)不過關(guān)導(dǎo)致，有些是誤操作導(dǎo)致。

實(shí)際場(chǎng)景中數(shù)據(jù)備份實(shí)施的壓力或阻力，主要來自存儲(chǔ)空間不足以及備份過程可能造成的對(duì)性能的影響。

除了備份的數(shù)據(jù)文件需要占用存儲(chǔ)空間，數(shù)據(jù)庫文件的可用性、一致性驗(yàn)證，同樣會(huì)占用大量的存儲(chǔ)空間（臨時(shí)），因此在實(shí)際遷移過程中，對(duì)存儲(chǔ)空間的需求，可能會(huì)大于現(xiàn)有數(shù)據(jù)庫的數(shù)據(jù)量的2倍（源端及目標(biāo)端都是如此）。因此，在重要業(yè)務(wù)場(chǎng)景中，遷移前，需要對(duì)數(shù)據(jù)備份所需的存儲(chǔ)空間做好評(píng)估并考慮備份空間的成本。

案例五

某局委辦業(yè)務(wù)由vmware環(huán)境遷移到政務(wù)云，在遷移前，筆者為客戶做了所有遷移主機(jī)的整機(jī)備份（導(dǎo)出到vmware外部的外部存儲(chǔ)中），事實(shí)證明這些環(huán)節(jié)（準(zhǔn)備存儲(chǔ)環(huán)境、溝通vmware運(yùn)維方、數(shù)據(jù)導(dǎo)出耗時(shí)等）導(dǎo)致的成本增加是值得的。

遷移過程很順利，在業(yè)務(wù)遷移到政務(wù)云正常服務(wù)完成業(yè)務(wù)交接大約1個(gè)月后，接到客戶電話，希望能夠通過遷移前備份的主機(jī)恢復(fù)數(shù)據(jù)。

問題原因

原因是一個(gè)ISV在新環(huán)境做業(yè)務(wù)升級(jí)時(shí)，安排了一個(gè)沒有經(jīng)驗(yàn)的新人，把數(shù)據(jù)庫軟件做了重新安裝，并刪除了原有數(shù)據(jù)。在協(xié)助客戶通過備份的鏡像恢復(fù)數(shù)據(jù)后（歷史數(shù)據(jù)，新增數(shù)據(jù)部分由ISV做了增補(bǔ)操作），客戶購買了政務(wù)云提供的災(zāi)備服務(wù)，開始定期對(duì)重要主機(jī)和數(shù)據(jù)做全量及增量備份，通過云上的容災(zāi)服務(wù)來避免或減少業(yè)務(wù)錯(cuò)誤或誤操作造成的損失。