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

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

云計(jì)算

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

網(wǎng)站設(shè)計(jì)制作過(guò)程拒絕使用模板建站；使用PHP+MYSQL原生開(kāi)發(fā)可交付網(wǎng)站源代碼;符合網(wǎng)站優(yōu)化排名的后臺(tái)管理系統(tǒng)；成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)收費(fèi)合理；免費(fèi)進(jìn)行網(wǎng)站備案等企業(yè)網(wǎng)站建設(shè)一條龍服務(wù).我們是一家持續(xù)穩(wěn)定運(yùn)營(yíng)了十多年的成都創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司。

前言

在支持京東集團(tuán)內(nèi)部及京東云外部客戶(hù)的業(yè)務(wù)遷移到京東公有云及京東私有云、京東政務(wù)云的過(guò)程中，京東科技-京東云事業(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ù)種類(lèi)繁多，主要類(lèi)型包括：

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

關(guān)系型數(shù)據(jù)庫(kù) 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)外部客戶(hù)在上云過(guò)程中，大部分業(yè)務(wù)均涉及到以上多種數(shù)據(jù)類(lèi)型，基于相關(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ò)相關(guān)業(yè)務(wù)安全部門(mén)審核。

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ì)量滿(mǎn)足遷移需求。

案例分析

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

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

MySQL：

MySQL在遷移中最為常見(jiàn)，也有很成熟的遷移工具和遷移方案，包括官方工具和相關(guān)開(kāi)源工具，如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ù)庫(kù)與目標(biāo)端數(shù)據(jù)庫(kù)與DTS管理服務(wù)IP網(wǎng)絡(luò)互通，并具備穩(wěn)定的網(wǎng)絡(luò)連接。

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

mysqldump工具：

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

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

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

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

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

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

舉例來(lái)說(shuō)，數(shù)據(jù)庫(kù)大小 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，來(lái)驗(yàn)證和評(píng)估生產(chǎn)環(huán)境的切換流程及耗時(shí)，制定生產(chǎn)業(yè)務(wù)割接的計(jì)劃時(shí)，要以這個(gè)時(shí)間為數(shù)據(jù)庫(kù)遷移的時(shí)長(zhǎng)依據(jù)。

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

案例一

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

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

在停服前的下午，為了給遷移留出足夠的時(shí)間緩沖，我們提前啟動(dòng)了主數(shù)據(jù)庫(kù)的DTS服務(wù)，數(shù)據(jù)庫(kù)遷移進(jìn)程正常進(jìn)行，預(yù)計(jì)遷移時(shí)長(zhǎng)為4小時(shí)，但是在DTS服務(wù)最后階段，因源端binlog問(wèn)題，出現(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ù)無(wú)法恢復(fù)，最終DTS傳輸?shù)?小時(shí)時(shí)間被浪費(fèi)，因遷移是系統(tǒng)工程，其他數(shù)據(jù)遷移進(jìn)程也都在根據(jù)計(jì)劃推進(jìn)，此時(shí)大家都沒(méi)有時(shí)間去分析具體原因。

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

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

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

源庫(kù)信息：—src-host sourceIP —src-user user —src-pass pass

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

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

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

準(zhǔn)備工作

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

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

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

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

案例二

某金融用戶(hù)，原系統(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ù)庫(kù)做了詳細(xì)調(diào)研，因?yàn)樵炊耸嵌ㄖ苹?、具有自?dòng)水平拆分、Shared Nothing 架構(gòu)的分布式數(shù)據(jù)庫(kù)，因此使用京東云的DTS工具不適用于這個(gè)場(chǎng)景，同時(shí)，在兩個(gè)環(huán)境，要求數(shù)據(jù)基本為實(shí)時(shí)同步才能滿(mǎn)足業(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)景無(wú)法適配，相關(guān)廠商也表示正在做向云上災(zāi)備的轉(zhuǎn)型，但尚未有成熟落地的產(chǎn)品（適配難度較大），因此最終方案采取了基于gtid的主從復(fù)制的方案來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)的異構(gòu)云同步，屏蔽了架構(gòu)差異帶來(lái)的問(wèn)題。

注意：涉及業(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è)停止寫(xiě)操作，在T云側(cè)和京東云側(cè)分別通過(guò)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è)通過(guò)創(chuàng)建測(cè)試表/增刪改查等操作驗(yàn)證ddl/dml是否正常復(fù)制。

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

為保障數(shù)據(jù)及業(yè)務(wù)災(zāi)備的可靠性，需要對(duì)網(wǎng)絡(luò)專(zhuān)線(xiàn)做實(shí)時(shí)的監(jiān)控及告警配置，當(dāng)出現(xiàn)網(wǎng)絡(luò)問(wèn)題時(shí)，需要能及時(shí)收到告警，第一時(shí)間處理，避免中間專(zhuān)線(xiàn)網(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ì)源庫(kù)的保護(hù)

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

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

二、ES遷移

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

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

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

Snapshot方式：

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

從速度和效率上來(lái)講，快照方式優(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)整需求或無(wú)法連接共享存儲(chǔ)的遷移場(chǎng)景，以及只需要遷移部分?jǐn)?shù)據(jù)的場(chǎng)景。

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

案例三

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

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

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

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

為滿(mǎn)足網(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可以一樣，也可以不同，通過(guò)reindex，可以實(shí)現(xiàn)修改mapping后的字段類(lèi)型。
• 可以從京東云側(cè)ES訪(fǎng)問(wèn)到源端云側(cè)服務(wù)的ES的服務(wù)端口，驗(yàn)證方式，telnet或curl -XGET??http://:9200??方式驗(yàn)證均可。

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

源ES集群

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

2.寫(xiě)入數(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)文件訪(fǎng)問(wèn)問(wè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ù)訪(fǎng)問(wèn)特性、業(yè)務(wù)停機(jī)窗口等信息，綜合考慮遷移流程和選擇技術(shù)方案。

案例四

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

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

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

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

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

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

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

文件list獲取配置示例：

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

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

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

3、 開(kāi)啟oss的鏡像回源。

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

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

在POC階段，做測(cè)試環(huán)境數(shù)據(jù)遷移時(shí)，采用這個(gè)方案驗(yàn)證一切順利，但是在生產(chǎn)環(huán)境割接時(shí)，遇到了問(wèn)題，判斷增量文件所需的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í)需要的是通過(guò)回源方式獲取一周內(nèi)新增的文件，如果list文件不正確，會(huì)導(dǎo)致增量的數(shù)據(jù)同步無(wú)法進(jìn)行。

問(wèn)題處理

業(yè)務(wù)割接時(shí)間有限，迅速升級(jí)問(wèn)題，將問(wèn)題反饋到工具軟件的研發(fā)同事，研發(fā)同事迅速投入排查（已是凌晨，為京東研發(fā)同學(xué)的敬業(yè)精神點(diǎn)個(gè)贊）。經(jīng)過(guò)研發(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ò)誤問(wèn)題，順利完成了文件list檢查，通過(guò)對(duì)比前后生成的list文件，獲取到新增的文件列表。配置鏡像回源，通過(guò)腳本同步了一周的新增文件，校驗(yàn)無(wú)誤后，配置業(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)制格式，類(lèi)似于快照，恢復(fù)直接覆蓋，aof保存的是命令（文本格式），類(lèi)似于追加模式，如果需要保留目標(biāo)端的redis的數(shù)據(jù)，可以使用aof方式，aof方式需要把源端redis做停寫(xiě)操作。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ì)的說(shuō)明（bgrewriteaof/bgsave/redisdump等），使用也相對(duì)簡(jiǎn)單，因此本文不多做介紹。

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

Redissycner通過(guò)docker部署方式：

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

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

下載客戶(hù)端軟件：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ù)，通過(guò)編寫(xiě)要執(zhí)?的任務(wù)json來(lái)配置操作環(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)都不過(guò)分的環(huán)節(jié)（也包括遷移后的一段時(shí)期），因數(shù)據(jù)備份不充分導(dǎo)致數(shù)據(jù)丟失、業(yè)務(wù)受損的教訓(xùn)很多，但是，在遷移實(shí)施過(guò)程中，因忽視數(shù)據(jù)備份而導(dǎo)致出現(xiàn)問(wèn)題的事件仍然很常見(jiàn)。

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

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

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

案例五

某局委辦業(yè)務(wù)由vmware環(huán)境遷移到政務(wù)云，在遷移前，筆者為客戶(hù)做了所有遷移主機(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)致的成本增加是值得的。

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

問(wèn)題原因

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

六、業(yè)務(wù)數(shù)據(jù)遷移總結(jié)

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

2、遷移技術(shù)及工具的選擇，現(xiàn)在數(shù)據(jù)遷移工具越來(lái)越多，各個(gè)大廠也都有自己的工具，但是產(chǎn)品的限制及兼容程度各有不同，需要根據(jù)業(yè)務(wù)性質(zhì)選擇并驗(yàn)證。

3、準(zhǔn)備回退預(yù)案，做好POC驗(yàn)證，POC能發(fā)現(xiàn)部分問(wèn)題，提前準(zhǔn)備解決方案。

4、做好流程手冊(cè)，明確操作責(zé)任人，聯(lián)系相關(guān)部門(mén)做好遷移的切換階段的護(hù)航準(zhǔn)備。產(chǎn)品和服務(wù)類(lèi)的問(wèn)題一定要能找到人支持。

5、明確責(zé)任矩陣、進(jìn)行全面溝通，溝通能夠發(fā)現(xiàn)技術(shù)層面很難發(fā)現(xiàn)的問(wèn)題，越早建立遷移組織并形成有限的溝通機(jī)制，對(duì)遷移的順利實(shí)施越有利。

本文題目：業(yè)務(wù)數(shù)據(jù)遷移上云的一些技術(shù)思考
轉(zhuǎn)載來(lái)源：http://www.fisionsoft.com.cn/article/cosceep.html