摘要：通過對(duì)一些客戶的跨云遷移過程進(jìn)行總結(jié)，發(fā)現(xiàn)普遍存在的挑戰(zhàn)有三點(diǎn)數(shù)據(jù)完整性和一致性挑戰(zhàn)。簡(jiǎn)而言之，跨云遷移過程中的數(shù)據(jù)一致性主要就集中在存量數(shù)據(jù)的遷移如何保證一致。

前言

隨著互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展對(duì)容災(zāi)以及對(duì)訪問加速、多供應(yīng)商成本控制等需求的產(chǎn)生，互聯(lián)網(wǎng)公司的多云部署和跨云遷移逐漸成為剛需，而在此過程中，最困擾運(yùn)維和研發(fā)人員的就是數(shù)據(jù)的遷移和同步。俗語說“ 上屋搬下屋，搬灑一籮谷 ”，在業(yè)務(wù)的遷移過程中一旦遇到重要數(shù)據(jù)的丟失，將會(huì)對(duì)企業(yè)造成巨大的損失。

UCloud通過對(duì)一些客戶的跨云遷移過程進(jìn)行總結(jié)，發(fā)現(xiàn)普遍存在的挑戰(zhàn)有三點(diǎn)：

1. 數(shù)據(jù)完整性和一致性挑戰(zhàn)。
2. 時(shí)效性，即遷移窗口期相對(duì)有限。
3. 應(yīng)用依賴性和各種調(diào)用關(guān)系。

跨云遷移涉及到的資源主要分成三大類：

第一類是EIP、VPC、負(fù)載均衡和NAT網(wǎng)關(guān)這類網(wǎng)絡(luò)服務(wù)，在跨云遷移的過程中這些都會(huì)發(fā)生變化，而且是無狀態(tài)服務(wù)，配置并不復(fù)雜，對(duì)于這部分資源可以通過人工的方法對(duì)齊配置。

第二類是最為常見的云主機(jī)資源，這部分我們可以通過UCloud服務(wù)器遷移工具USMC，以相同的配置在UCloud公有云上創(chuàng)建一份，只需保持和源端服務(wù)器IP一致的目標(biāo)端服務(wù)器IP，支持按分鐘級(jí)別進(jìn)行增量數(shù)據(jù)同步，減少業(yè)務(wù)切換的時(shí)間。

而第三類就是包括數(shù)據(jù)庫、文件存儲(chǔ)和對(duì)象存儲(chǔ)在內(nèi)的一些存儲(chǔ)服務(wù)，我們可以通過UDTS數(shù)據(jù)傳輸工具進(jìn)行遷移，而這一部分也正是本文重點(diǎn)討論的實(shí)踐內(nèi)容。

通常，我們將跨云遷移劃分為三個(gè)階段： 數(shù)據(jù)同步階段、數(shù)據(jù)規(guī)整階段(清理測(cè)試時(shí)產(chǎn)生的臟數(shù)據(jù))和數(shù)據(jù)割接階段。數(shù)據(jù)同步階段主要是需要解決兩個(gè)問題，首先是將數(shù)據(jù)復(fù)制到新平臺(tái)，并且讓應(yīng)用程序在新平臺(tái)運(yùn)行，這也是跨云遷移的核心；其次就是利用真實(shí)數(shù)據(jù)對(duì)應(yīng)用程序進(jìn)行測(cè)試，確認(rèn)應(yīng)用程序在目標(biāo)平臺(tái)可以符合預(yù)期地運(yùn)行。

我們知道數(shù)據(jù)可以分為結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，用來存儲(chǔ)數(shù)據(jù)的方法眾多，接下來主要介紹數(shù)據(jù)同步階段中常見的存儲(chǔ)組件例如MySQL、文件存儲(chǔ)和對(duì)象存儲(chǔ)的數(shù)據(jù)遷移實(shí)踐。其它不同的存儲(chǔ)組件各有不同，但也是可以參考這幾個(gè)組件的遷移邏輯來處理的。

MySQL同步

一般來說，我們認(rèn)為對(duì)于MySQL的同步，只要存量數(shù)據(jù)和增量數(shù)據(jù)都能做到一致，那么整個(gè)數(shù)據(jù)庫的同步就是一致的。而常見的MySQL數(shù)據(jù)遷移方式有兩種：一種是基于MySQL主從的方式，通過mysqldump記錄下binlog位置，然后把這個(gè)binlog位置前的數(shù)據(jù)完整導(dǎo)出，恢復(fù)出一個(gè)備庫，然后再從記錄的binlog位置開始向主庫追平增量數(shù)據(jù)。

另一種就是UDTS工具，總體上也是分為存量階段和增量階段，增量階段的追及是將從存量同步發(fā)起的一瞬間開始往后的數(shù)據(jù)變化通過binlog的形式同步到目標(biāo)庫。增量同步依靠binlog完成，這是MySQL主從同步的基礎(chǔ)，是我們需要默認(rèn)信任的數(shù)據(jù)一致性機(jī)制，當(dāng)然我們最終需要以數(shù)據(jù)校驗(yàn)結(jié)果來確認(rèn)數(shù)據(jù)是否一致。簡(jiǎn)而言之， 跨云遷移過程中MySQL的數(shù)據(jù)一致性主要就集中在存量數(shù)據(jù)的遷移如何保證一致。

【案例】

以近期的xx公司遷移到UCloud為例，其涉及數(shù)據(jù)庫實(shí)例有數(shù)十個(gè)，并且由于應(yīng)用依賴的原因需要進(jìn)行整體遷移。在這案例中，如果采用mysqldump的方法，那么這數(shù)十個(gè)數(shù)據(jù)庫都需要經(jīng)過導(dǎo)出、傳輸、導(dǎo)入和配置主從這樣的操作，給整個(gè)遷移任務(wù)增加了不少工作量。

同時(shí)也正如很多商業(yè)智能應(yīng)用需要將數(shù)據(jù)匯總用作分析，這家公司的業(yè)務(wù)系統(tǒng)也有類似的匯總數(shù)據(jù)庫，這種級(jí)聯(lián)關(guān)系會(huì)讓數(shù)據(jù)同步操作進(jìn)一步復(fù)雜化。最終該公司使用了UDTS作為跨云數(shù)據(jù)同步的解決方案，在保障數(shù)據(jù)一致的同時(shí)，DBA只需要提供兩邊數(shù)據(jù)庫的連接和賬號(hào)信息即可將數(shù)據(jù)同步任務(wù)托管，釋放了運(yùn)維人員的精力，專注去處理業(yè)務(wù)上的數(shù)據(jù)庫工作需求。

數(shù)據(jù)同步

前面提到MySQL事務(wù)，在理解存量數(shù)據(jù)遷移過程中的數(shù)據(jù)一致性時(shí)，需要先了解InnoDB為代表的事務(wù)引擎和MyISAM代表的非事務(wù)引擎。使用MyISAM引擎的數(shù)據(jù)表確實(shí)沒有很好的數(shù)據(jù)一致性確保手段，存量數(shù)據(jù)只能對(duì)數(shù)據(jù)表加讀鎖并遷移，在完成存量數(shù)據(jù)同步后，通過binlog追平，這樣因?yàn)樽x鎖會(huì)阻塞數(shù)據(jù)的寫入，會(huì)導(dǎo)致業(yè)務(wù)的寫入功能不可用，而且這一不可用的時(shí)間視表中數(shù)據(jù)體量而定。

然而因?yàn)镸yISAM的不靈活，實(shí)際互聯(lián)網(wǎng)公司中已經(jīng)很少使用MyISAM引擎了。而InnoDB引擎因?yàn)樗С质聞?wù)和行級(jí)鎖的特性，在數(shù)據(jù)同步過程中對(duì)業(yè)務(wù)的影響小很多，但也因此對(duì)數(shù)據(jù)一致性的保護(hù)方法也相對(duì)復(fù)雜，而這一套一致性保護(hù)方法，核心就在于基于連接session的事務(wù)隔離和基于MVCC的數(shù)據(jù)版本管理，而UDTS也正是基于此而實(shí)現(xiàn)數(shù)據(jù)一致。

數(shù)據(jù)校驗(yàn)

數(shù)據(jù)一致性的關(guān)鍵，除了數(shù)據(jù)同步過程中的一致性保障，更加簡(jiǎn)單直接的手段是數(shù)據(jù)校驗(yàn)，只有對(duì)比過數(shù)據(jù)是一致的，那才是真正的一致。MySQL數(shù)據(jù)校驗(yàn)的手段有很多，其中最經(jīng)典的是pt-table-checksum。

pt-table-checksum會(huì)新建一個(gè)臨時(shí)的checksum表，并且獲取與主庫有主從關(guān)系的所有從庫信息。在校驗(yàn)工作時(shí)，工具會(huì)將該session的binlog格式設(shè)置為statement，這樣是為了利用mysql的binlog機(jī)制，將主庫上執(zhí)行的sql語句同步到從庫去。接著工具會(huì)以chunk為單位從主庫中讀取數(shù)據(jù)和計(jì)算校驗(yàn)，將校驗(yàn)結(jié)果寫入checksum表，這個(gè)過程會(huì)在一個(gè)語句中完成，隨后這個(gè)語句由于對(duì)checksum表進(jìn)行修改，會(huì)被同步到從庫并且被從庫執(zhí)行。這樣從庫也會(huì)在自己的checksum表寫入校驗(yàn)值。這個(gè)時(shí)候工具再從庫中把checksum值讀出，就可以與主庫的計(jì)算值進(jìn)行對(duì)比。

pt-table-checksum的優(yōu)勢(shì)在于使用方便，在經(jīng)歷了多年迭代也有非常好的可靠性保證。但是它的技術(shù)限制也是明顯，那就是要求被校驗(yàn)的兩個(gè)庫需要是主從關(guān)系，同時(shí)也要求數(shù)據(jù)表有索引，因?yàn)閏hunk大小的計(jì)算是通過索引完成的。

【案例】
以近期的xx公司遷移到UCloud為例，在數(shù)據(jù)同步的階段由于數(shù)據(jù)庫實(shí)例眾多，需要減少DBA的工作負(fù)擔(dān)而采用了UDTS來進(jìn)行數(shù)據(jù)庫遷移，但是這樣就打破了源和目標(biāo)庫的主從關(guān)系，進(jìn)而導(dǎo)致pt-table-checksum無法使用。當(dāng)然實(shí)際上數(shù)據(jù)導(dǎo)出-傳輸-導(dǎo)入-配置主從這樣的機(jī)械化操作可以通過制作腳本來解決，但是為了遷移而開發(fā)一套復(fù)用率不高的腳本代碼并不明智。這時(shí)候sync_diff_inspector工具的優(yōu)勢(shì)就體現(xiàn)出來了。

sync_diff_inspector是TiDB團(tuán)隊(duì)為了方便用戶在MySQL數(shù)據(jù)遷移到TiDB后對(duì)數(shù)據(jù)一致性進(jìn)行檢查的開源工具，它不要求被校驗(yàn)的兩個(gè)數(shù)據(jù)庫存在主從關(guān)系，也沒有對(duì)數(shù)據(jù)表索引的要求，甚至允許源庫和目標(biāo)庫有不同的庫名和表名，只要有明確的映射，就可以對(duì)數(shù)據(jù)本身進(jìn)行校驗(yàn)。同時(shí)，在sync_diff_inspector發(fā)現(xiàn)某一塊數(shù)據(jù)存在差異的時(shí)候，會(huì)通過二分對(duì)比的辦法，最終找到實(shí)際不一致的行，縮小了疑似不一致的數(shù)據(jù)范圍。

雖然這種相對(duì)松耦合的環(huán)境下對(duì)數(shù)據(jù)進(jìn)行校驗(yàn)，可能會(huì)出現(xiàn)記錄下一些數(shù)據(jù)不一致，例如主庫的某個(gè)寫入還沒有完全即時(shí)的同步到從庫，這時(shí)候進(jìn)行檢查可能會(huì)存在數(shù)據(jù)差異，但是除非源庫insert/delete/update操作非常頻繁，否則一般期望工具檢查發(fā)現(xiàn)的差異不會(huì)太多。這時(shí)候只需要針對(duì)檢查報(bào)告中的少數(shù)差異做第二次的手工或腳本校驗(yàn)，就可以確認(rèn)數(shù)據(jù)一致性。當(dāng)然如果一致性檢查工具發(fā)現(xiàn)有較多數(shù)據(jù)不一致，一是可以用檢查工具生成的一致性修復(fù)腳本來修復(fù)一致性，也可以對(duì)通過對(duì)數(shù)據(jù)進(jìn)行重新同步來完成。

需要留意的是，pt-table-checksum和sync_diff_inspector都是對(duì)實(shí)體數(shù)據(jù)進(jìn)行校驗(yàn)的工具，在數(shù)據(jù)量較大的情況下校驗(yàn)操作會(huì)相對(duì)緩慢，不適合在割接時(shí)間窗口中操作。在實(shí)際項(xiàng)目中筆者測(cè)得一個(gè)500G的數(shù)據(jù)庫的完整校驗(yàn)耗時(shí)大約28小時(shí)。在割接時(shí)間窗口中，一般通過select max(id)或者select count(id)對(duì)數(shù)據(jù)進(jìn)行簡(jiǎn)單對(duì)比。

文件存儲(chǔ)同步

文件同步

相比于MySQL，文件作為一種非結(jié)構(gòu)化的存儲(chǔ)方式，遷移方法相對(duì)較少，也沒有太多的數(shù)據(jù)一致性保障方法。與此同時(shí)，海量小文件的處理效率有限一直都是技術(shù)難題。

一般來說，文件存儲(chǔ)的方式一般是硬盤本地存儲(chǔ)或者基于NFS協(xié)議的存儲(chǔ)服務(wù)，這兩種存儲(chǔ)服務(wù)中NFS存儲(chǔ)的同步會(huì)更困難一些。單個(gè)文件的同步是簡(jiǎn)單的，將文件復(fù)制到目標(biāo)空間然后再對(duì)文件計(jì)算md5校驗(yàn)和，只要兩邊的數(shù)據(jù)是一致的就行。難點(diǎn)在于獲知文件是否有發(fā)生變化。在linux kernel中可以利用 inotify機(jī)制了解到本機(jī)對(duì)文件的修改動(dòng)作。

inotify應(yīng)用在啟動(dòng)的時(shí)候除了初始化監(jiān)聽和創(chuàng)建事件隊(duì)列以外，還會(huì)在文件系統(tǒng)操作的函數(shù)中加入inotify hook函數(shù)以將文件系統(tǒng)事件通知到inotify系統(tǒng)中，這些都是操作系統(tǒng)內(nèi)核中的系統(tǒng)調(diào)用。所以對(duì)于NFS而言inotify就失效了，因?yàn)橄嚓P(guān)調(diào)用都是本機(jī)環(huán)境中的系統(tǒng)調(diào)用而沒有經(jīng)過網(wǎng)絡(luò)，掛載了同一個(gè)NFS的多臺(tái)主機(jī)沒有機(jī)制了解對(duì)方在什么時(shí)候?qū)ξ募M(jìn)行了操作。

所以這時(shí)候，從業(yè)務(wù)中對(duì)出現(xiàn)變化的文件進(jìn)行記錄就很有必要，因?yàn)閷?shí)際上所有對(duì)文件的增、刪、改都是業(yè)務(wù)所需的操作行為。所以在數(shù)據(jù)同步階段，我們依然通過rsync或類似方法來同步數(shù)據(jù)，并且通過業(yè)務(wù)日志記錄發(fā)生了變化的文件，最后在割接階段解析業(yè)務(wù)日志，將出現(xiàn)過變化的文件做最后的增量同步，從而實(shí)現(xiàn)數(shù)據(jù)追平。

典型的組件可以參考FastDFS，F(xiàn)astDFS實(shí)現(xiàn)了類似binlog的方式，來記錄每個(gè)storaged接受到哪些文件的更新，是哪種更新操作。在啟動(dòng)storaged之后，就可以實(shí)現(xiàn)自動(dòng)讀取其它同副本關(guān)系的storaged的數(shù)據(jù)來恢復(fù)。例如大C表示源創(chuàng)建，小c表示創(chuàng)建副本，大A表示源追加，小a標(biāo)識(shí)副本追加，大D表示源刪除，小d表示副本刪除等等。

實(shí)際生產(chǎn)環(huán)境中的fastdfs binlog

當(dāng)然也有一些實(shí)現(xiàn)了分布式鎖的文件系統(tǒng)，例如vmware的vmfs和oracle的ocfs，可以共享文件系統(tǒng)數(shù)據(jù)的同時(shí)，通過鎖機(jī)制來實(shí)現(xiàn)操作系統(tǒng)對(duì)文件變化的感知。

文件校驗(yàn)

文件的校驗(yàn)，這里會(huì)涉及到存儲(chǔ)靜默錯(cuò)誤的問題。我們回憶硬盤壞道這個(gè)概念，就會(huì)發(fā)現(xiàn)硬盤自己也不知道某個(gè)扇區(qū)目前狀態(tài)是否良好，需要專門進(jìn)行掃描才能確認(rèn)。一個(gè)扇區(qū)寫了數(shù)據(jù)，在長久的運(yùn)行中這一扇區(qū)成為了壞道導(dǎo)致不能讀出數(shù)據(jù)，這時(shí)候應(yīng)用不讀取就不知道底層數(shù)據(jù)出現(xiàn)問題，這就是靜默錯(cuò)誤。

要解決靜默錯(cuò)誤的唯一辦法是全鏈路數(shù)據(jù)校驗(yàn)：

• 在數(shù)據(jù)上傳前，確認(rèn)數(shù)據(jù)正常，生成校驗(yàn)和；
• 上傳到某個(gè)存儲(chǔ)服務(wù)之后，存儲(chǔ)服務(wù)存儲(chǔ)文件并且記錄這個(gè)文件的校驗(yàn)和；
• 定期對(duì)數(shù)據(jù)進(jìn)行巡檢，重新計(jì)算文件校驗(yàn)和并且和記錄值比較；
• 取出數(shù)據(jù)時(shí)，也對(duì)數(shù)據(jù)進(jìn)行校驗(yàn)和比較，這樣才能保證文件數(shù)據(jù)一致。

因此從技術(shù)層面來說建議從一開始就使用帶有全鏈路數(shù)據(jù)校驗(yàn)功能的服務(wù)，自建存儲(chǔ)服務(wù)的全鏈路一致性也需要自行建設(shè)，否則在遷移后只能通過md5sum這類工具對(duì)全部數(shù)據(jù)進(jìn)行校驗(yàn)，確保遷移前后數(shù)據(jù)沒有差異，而不保證遷移后的文件依然是訪客當(dāng)初上傳的文件。盡管需要做這樣的妥協(xié)，海量小文件的遷移和校驗(yàn)依然會(huì)造成遷移工期的壓力。

利用md5sum遞歸遍歷整個(gè)目錄，生成所有文件的md5結(jié)果，可以通過以下命令完成：

find ./ -type f -print0 | xargs -0 md5sum > ./my.md5

相應(yīng)的，可以通過以下命令對(duì)遷移后的整個(gè)目錄進(jìn)行遞歸遍歷校驗(yàn)。

md5sum -c my.md5

對(duì)象存儲(chǔ)同步

數(shù)據(jù)同步

對(duì)象存儲(chǔ)的數(shù)據(jù)同步和校驗(yàn)的復(fù)雜度介于數(shù)據(jù)庫和文件存儲(chǔ)之間，因?yàn)樗旧鲜腔贖TTP協(xié)議的，鏡像回源的功能就能派上用場(chǎng)了，即如果一個(gè)文件在我們平臺(tái)上不存在，那對(duì)象存儲(chǔ)會(huì)嘗試到源站去獲取并保存下來。而相對(duì)于InnoDB數(shù)據(jù)表這種結(jié)構(gòu)化數(shù)據(jù)，對(duì)象存儲(chǔ)的數(shù)據(jù)一致性保障還是相對(duì)較弱。

目前市面上各種平臺(tái)的對(duì)象存儲(chǔ)服務(wù)對(duì)S3協(xié)議都有較好支持，而通過US3SYNC工具就可以將其他支持S3協(xié)議的對(duì)象存儲(chǔ)數(shù)據(jù)遷移到UCloud對(duì)象存儲(chǔ)US3中。雖然US3也支持鏡像回源，但是在數(shù)據(jù)同步的剛開始時(shí)，不建議將原平臺(tái)bucket配置為回源目標(biāo)之后就將US3作為服務(wù)入口來使用起來，因?yàn)檫@個(gè)時(shí)候US3 bucket中還沒有數(shù)據(jù)，直接使用US3會(huì)造成大量鏡像回源，一是從而導(dǎo)致整體訪問延遲變大，其次也容易出現(xiàn)訪問失敗的情況。

US3SYNC工具與redis協(xié)同工作。在數(shù)據(jù)同步開始前，US3SYNC工具會(huì)通過S3協(xié)議的列表接口，將一定數(shù)量的源bucket對(duì)象key以及這些key的同步狀態(tài)記錄進(jìn)redis中。每當(dāng)一個(gè)文件完成從源bucket的下載、緩存和上傳到US3后，導(dǎo)入工具就會(huì)在redis中將數(shù)據(jù)標(biāo)記為已同步。這樣在US3SYNC工具因?yàn)橐恍┛赡艿脑?，例如網(wǎng)絡(luò)環(huán)境不好等問題故障掛起之后，只需要重啟US3SYNC，它都可以從斷點(diǎn)開始續(xù)傳。

當(dāng)完成一輪數(shù)據(jù)導(dǎo)入之后，就可以開始配置鏡像回源配置了，這時(shí)候直接訪問US3也能得到不錯(cuò)的命中率。當(dāng)然也可以選擇再運(yùn)行一次US3SYNC工具，如果這樣操作需要注意US3SYNC工具原本的功能是斷點(diǎn)續(xù)傳的，所以我們應(yīng)該把redis的內(nèi)容清除。

但是直接清理掉redis再重新跑，US3SYNC工具的行為是重新加載文件列表并且重新寫入U(xiǎn)S3，這樣會(huì)導(dǎo)致所有數(shù)據(jù)都要重新寫一次，效率很低。在這個(gè)時(shí)候，我們可以配置US3SYNC工具為文件比對(duì)模式，在獲取文件列表后將文件都通過HEAD獲取文件大小，這時(shí)候只要將源bucket HEAD成功，但是US3為not found或者文件大小不同的數(shù)據(jù)同步到US3即可。在實(shí)際的數(shù)據(jù)遷移實(shí)踐中，我們可以更加靈活的使用續(xù)傳和比對(duì)模式來提高工作效率。

【案例】
以近期的xx公司遷移到UCloud為例，該公司的CDN和對(duì)象存儲(chǔ)從友商遷移到UCloud的過程里面，有一個(gè)bucket中存在文件數(shù)量達(dá)到了12億，將所有key存儲(chǔ)到redis中并不合理，會(huì)導(dǎo)致redis數(shù)據(jù)膨脹，進(jìn)而對(duì)遷移中轉(zhuǎn)主機(jī)提出非常高的內(nèi)存需求。這時(shí)候應(yīng)該從一開始就配置US3SYNC工具為文件比對(duì)模式對(duì)數(shù)據(jù)進(jìn)行遷移，進(jìn)而避免不合理的redis內(nèi)存使用。

數(shù)據(jù)校驗(yàn)

對(duì)象存儲(chǔ)的數(shù)據(jù)校驗(yàn)方面，大多數(shù)對(duì)象存儲(chǔ)都支持給文件提供ETag的Header，且ETag的生成都跟原始數(shù)據(jù)有一定關(guān)系，所以可以根據(jù)源平臺(tái)的ETag計(jì)算方式，在下載到文件后對(duì)文件進(jìn)行一次計(jì)算，看看ETag是否相符。而US3SYNC功能本身也會(huì)按照US3的ETag計(jì)算規(guī)則預(yù)先計(jì)算我們的ETag，在上傳成功后對(duì)比US3返回的ETag和導(dǎo)入工具自行計(jì)算的值，來實(shí)現(xiàn)對(duì)數(shù)據(jù)的校驗(yàn)。

寫在最后

多云部署已成趨勢(shì)，在幫助平臺(tái)用戶進(jìn)行多云部署和數(shù)據(jù)遷移的過程中，UCloud技術(shù)團(tuán)隊(duì)摸索和積累了豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)。為了在有限的業(yè)務(wù)窗口期將海量數(shù)據(jù)進(jìn)行遷移， UCloud服務(wù)器遷移中心USMC和數(shù)據(jù)傳輸工具UDTS，助力用戶在保證數(shù)據(jù)完整性和一致性的前提下，大大提升了多云部署的數(shù)據(jù)同步效率。

由于篇幅限制，本文只對(duì)數(shù)據(jù)同步階段中的存儲(chǔ)組件MySQL、文件存儲(chǔ)和對(duì)象存儲(chǔ)的數(shù)據(jù)遷移過程進(jìn)行了解析，下一篇將介紹跨云遷移中數(shù)據(jù)規(guī)整階段(清理測(cè)試時(shí)產(chǎn)生的臟數(shù)據(jù))和數(shù)據(jù)割接階段的實(shí)現(xiàn)細(xì)節(jié)。