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

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

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

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

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

　　通常，我們將跨云遷移劃分為三個階段： 數(shù)據(jù)同步階段、數(shù)據(jù)規(guī)整階段（清理測試時產(chǎn)生的臟數(shù)據(jù)）和數(shù)據(jù)割接階段。數(shù)據(jù)同步階段主要是需要解決兩個問題，首先是將數(shù)據(jù)復(fù)制到新平臺，并且讓應(yīng)用程序在新平臺運行，這也是跨云遷移的核心；其次就是利用真實數(shù)據(jù)對應(yīng)用程序進(jìn)行測試，確認(rèn)應(yīng)用程序在目標(biāo)平臺可以符合預(yù)期地運行。我們知道數(shù)據(jù)可以分為結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，用來存儲數(shù)據(jù)的方法眾多，本文主要介紹數(shù)據(jù)同步階段中常見的存儲組件例如MySQL、文件存儲和對象存儲的數(shù)據(jù)遷移實踐。其它不同的存儲組件各有不同，但也是可以參考這幾個組件的遷移邏輯來處理的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　對象存儲的數(shù)據(jù)同步和校驗的復(fù)雜度介于數(shù)據(jù)庫和文件存儲之間，因為它基本上是基于HTTP協(xié)議的，鏡像回源的功能就能派上用場了，即如果一個文件在我們平臺上不存在，那對象存儲會嘗試到源站去獲取并保存下來。而相對于InnoDB數(shù)據(jù)表這種結(jié)構(gòu)化數(shù)據(jù)，對象存儲的數(shù)據(jù)一致性保障還是相對較弱。

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

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

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

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

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

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

　　正如前面提到，為了了解新平臺中應(yīng)用是否能正常運行，一般來說遷移過程中涉及到的應(yīng)用測試都會盡量使用真實數(shù)據(jù)，甚至采用流量重放的方法對新系統(tǒng)進(jìn)行測試，以便通過對比原平臺環(huán)境中真實行為的結(jié)果來校驗新平臺應(yīng)用是否正常工作。

　　在測試之后，新平臺就會出現(xiàn)臟數(shù)據(jù)，需要對其進(jìn)行處理。通常臟數(shù)據(jù)的處理有兩種思路可以使用，其一是回滾，就是在開展業(yè)務(wù)測試前先對數(shù)據(jù)進(jìn)行備份或者記錄還原點。對于MySQL數(shù)據(jù)庫可以基于binlog進(jìn)行回滾，也可以通過云平臺能力進(jìn)行數(shù)據(jù)庫備份和回滾，但是需要注意備份時暫停UDTS任務(wù)以及其它寫入，以及記錄binlog位置。對于文件存儲和對象存儲，文件變更日志的作用就很顯著了，所有變更過的文件從日志中解析出來之后從源頭重新同步，這樣可以避免所有文件的重新同步。

　　當(dāng)然也可以丟掉全部臟數(shù)據(jù)，采取與數(shù)據(jù)同步階段相同的數(shù)據(jù)遷移手段對數(shù)據(jù)進(jìn)行重新同步，這樣雖然慢一些，但是整個數(shù)據(jù)同步過程就是冪等的，可重復(fù)性更強。兩種臟數(shù)據(jù)的處理方式可以根據(jù)實際數(shù)據(jù)量靈活采用。

　　在割接準(zhǔn)備階段時候進(jìn)行的數(shù)據(jù)同步所得到的數(shù)據(jù)就是割接和割接后的生產(chǎn)數(shù)據(jù)了，所以需要通過一定的手段，保障數(shù)據(jù)的持續(xù)同步，同時避免數(shù)據(jù)被意外修改。下面說說幾種保障的辦法。

　　對于MySQL而言，通過對數(shù)據(jù)同步和業(yè)務(wù)應(yīng)用設(shè)置不同的賬戶，并且對不同用戶分配不同的權(quán)限，這幾乎是最簡單易行的實踐方式。設(shè)立數(shù)據(jù)同步賬戶，賦予增刪查改權(quán)限和DDL語句的權(quán)限，這樣可以滿足存量和增量數(shù)據(jù)同步的需要，然后將數(shù)據(jù)同步賬戶嚴(yán)格控制只配置給UDTS數(shù)據(jù)同步工具和sync_diff_inspector數(shù)據(jù)校驗工具。

　　而對于業(yè)務(wù)應(yīng)用的配置文件，或者記錄到配置中心中的配置，上面所使用的數(shù)據(jù)庫賬戶就只分配select語句權(quán)限，這樣就能保障業(yè)務(wù)應(yīng)用、腳本或者各種定時任務(wù)都無法對數(shù)據(jù)進(jìn)行更改。而且這樣做還有一個好處，對于一些沒有實現(xiàn)數(shù)據(jù)庫重連邏輯的業(yè)務(wù)應(yīng)用，這時候數(shù)據(jù)庫是可以正常連接的，這意味著在數(shù)據(jù)割接的時候不需要重啟應(yīng)用，而是只需要調(diào)整MySQL中業(yè)務(wù)賬戶的權(quán)限。

　　對于一些場景，不重啟對于割接過程來說是非常重要的。例如由于分布式框架的引入，對象和方法可以輕松的通過RPC獲取，這時候業(yè)務(wù)團(tuán)隊也專注于業(yè)務(wù)的實現(xiàn)，忽略了底層重連機(jī)制的實現(xiàn)。結(jié)果就是應(yīng)用系統(tǒng)成為了一個分布式的緊耦合系統(tǒng)，主機(jī)A上某個進(jìn)程的正常運行需要依賴主機(jī)B上進(jìn)程的正常運行，而且B還不能隨便重啟，因為重啟后A不會重連。這時候如果應(yīng)用不用重啟，那意味著清理臟數(shù)據(jù)后，應(yīng)用保持當(dāng)前的運行狀態(tài)即可，而不是調(diào)查所有應(yīng)用的啟動順序，在割接時確認(rèn)數(shù)據(jù)同步后再按順序逐個啟動，這樣有利于提升割接后的業(yè)務(wù)穩(wěn)定性和降低割接操作的復(fù)雜度。

　　然而，通過數(shù)據(jù)庫只讀來保障數(shù)據(jù)一致性的方式受限也會比較多，例如MySQL有基于用戶的只讀方法，同時Redis、SQLServer、MongoDB、Elastic Search、文件存儲、對象存儲等等組件又有各自不同的只讀方法，在組件數(shù)量和種類增加以后，這種操作方式的優(yōu)勢會逐漸喪失。

　　因此，數(shù)據(jù)庫只讀的方式適用于MySQL數(shù)據(jù)庫且實例數(shù)量不多的情況，例如整體遷移以模塊化方式進(jìn)行的情況。另外對于需要盡量減少應(yīng)用重啟的系統(tǒng)也可以優(yōu)先考慮這種方式來保障數(shù)據(jù)一致性。

　　前面提到，在一些應(yīng)用系統(tǒng)里重啟應(yīng)用并不是易事，但有一些應(yīng)用系統(tǒng)，重啟造成的困擾并沒有那么大，可以相對自由的重啟應(yīng)用。實際上對于一個系統(tǒng)而言，會有三類程序可能對數(shù)據(jù)存儲進(jìn)行修改，分別是應(yīng)用程序和操作系統(tǒng)定時任務(wù)腳本，對于數(shù)據(jù)庫而言還需要多加一個定時任務(wù)。只需要保證這三類程序都是停止的，那么就可以保證沒有同步服務(wù)以外的程序?qū)��?shù)據(jù)進(jìn)行修改，從而保障數(shù)據(jù)一致性。

　　通過這種方法來保證數(shù)據(jù)不被意外修改的優(yōu)勢在于它是普遍適用的，不管提供存儲服務(wù)的是數(shù)據(jù)庫或者其他類型的存儲組件，只要進(jìn)程停了數(shù)據(jù)就不可能被修改。

　　但是這種處理方法的限制也是很明顯的，首先就是應(yīng)用可以隨意重啟。其次是在分布式環(huán)境下面，需要具備批量的啟動或者關(guān)閉應(yīng)用程序，以及修改操作系統(tǒng)定時任務(wù)的能力，不管是基于Ansible或者其他方式。除此以外也需要確保生產(chǎn)環(huán)境中應(yīng)用程序和腳本的統(tǒng)計是正確的，也就是說所有應(yīng)用程序和腳本都是運維和開發(fā)共同知曉的。例如運維為了短時間方便，編寫腳本作用在生產(chǎn)環(huán)境的數(shù)據(jù)而不被其他同事所了解，那在停止應(yīng)用的時候自然也不會被考慮到。

　　總結(jié)來說，結(jié)束應(yīng)用程序的方式適合應(yīng)用可以各自獨立啟停，且生產(chǎn)環(huán)境應(yīng)用、腳本和數(shù)據(jù)庫定時任務(wù)都完全統(tǒng)計清楚明確的情況下使用。

　　通過ACL網(wǎng)絡(luò)對數(shù)據(jù)存儲服務(wù)做隔離是一個操作上相對比較簡單的方法。簡單來說，就是在網(wǎng)絡(luò)環(huán)境上配置ACL，允許數(shù)據(jù)同步服務(wù)連接存儲并且禁止其它應(yīng)用主機(jī)連接。這種方法的優(yōu)勢在于規(guī)則的套用和解除都相對簡單，在數(shù)據(jù)同步時直接對整個VPC子網(wǎng)生效，在割接時候只需要在控制臺上解除，從而對整個VPC子網(wǎng)的存儲服務(wù)做到批量控制。而且相比于數(shù)據(jù)庫只讀和結(jié)束應(yīng)用進(jìn)程這兩種方法，通過網(wǎng)絡(luò)ACL進(jìn)行隔離則不用依賴于運維團(tuán)隊對全系統(tǒng)所有細(xì)節(jié)的掌握，對所有基于網(wǎng)絡(luò)的存儲服務(wù)進(jìn)行覆蓋，可以說完全具備了前面兩種數(shù)據(jù)一致性保護(hù)方式的優(yōu)點。

　　當(dāng)然ACL網(wǎng)絡(luò)隔離的方法也有它的適用場景限制。其中最主要的是這種方式的實施要求運維團(tuán)隊對各個子網(wǎng)的功能劃分是清晰明確的，網(wǎng)絡(luò)入口、業(yè)務(wù)應(yīng)用和數(shù)據(jù)存儲分別在不同的子網(wǎng)，所以如果應(yīng)用習(xí)慣了大二層的部署方式，那么網(wǎng)絡(luò)ACL的批量管理優(yōu)勢就會大打折扣。其次，由于對應(yīng)用的網(wǎng)絡(luò)中斷，因此對于沒有重連機(jī)制的應(yīng)用，網(wǎng)絡(luò)重新開通后依然需要重啟應(yīng)用。最后，這一方法對于不連網(wǎng)絡(luò)的應(yīng)用是無法限制的，例如云硬盤本地存儲，這種情況需要以掛載云硬盤的主機(jī)為單位去考慮網(wǎng)絡(luò)隔離。

　　經(jīng)過對上面三種保障數(shù)據(jù)一致性方法的對比，可以發(fā)現(xiàn)這三種方法其實并沒有相互沖突的點，在實際中我們可以靈活組合來匹配更多業(yè)務(wù)環(huán)境的要求，例如同時使用結(jié)束應(yīng)用進(jìn)程和ACL網(wǎng)絡(luò)隔離。

　　在XX公司的跨云遷移任務(wù)中，我們在前期調(diào)研中發(fā)現(xiàn)了幾個問題。首先是數(shù)據(jù)庫實例數(shù)量眾多，源庫和目標(biāo)庫既有自建的也有云平臺產(chǎn)品，具體操作方式各有差異；其次是數(shù)據(jù)存儲服務(wù)種類眾多，除了MySQL以外，還有MongoDB、SQL Server、NFS存儲、Elastic Search等，逐個組件去設(shè)計讀寫-只讀切換的邏輯需要運維人員很大的精力投入。另一方面，由于目標(biāo)系統(tǒng)對存儲和應(yīng)用有比較好的網(wǎng)段劃分，雖然組件眾多，但是至少都在相同子網(wǎng)內(nèi)，適合使用ACL來隔離。最后，由于應(yīng)用層面沒有讀寫-只讀的切換開關(guān)，也沒有實現(xiàn)重連機(jī)制。

　　所以，在實際操作過程中，我們推薦客戶使用了結(jié)束應(yīng)用進(jìn)程和ACL網(wǎng)絡(luò)隔離的雙重保險，因為應(yīng)用不具備重連實現(xiàn)的情況下，割接測試前應(yīng)用至少需要重啟一次，ACL和結(jié)束應(yīng)用的限制都會被接受。與此同時，ACL隔離也補充了結(jié)束應(yīng)用的覆蓋面，從網(wǎng)絡(luò)層面保障不會有數(shù)據(jù)同步組件以外的系統(tǒng)連接到數(shù)據(jù)存儲層面來進(jìn)行操作。

　　不管是整體割接，還是以業(yè)務(wù)模塊為單位的割接，時間窗口大小總是有限的，而且從業(yè)務(wù)角度也希望割接窗口越小越好。

　　數(shù)據(jù)校驗最早應(yīng)該在完成數(shù)據(jù)規(guī)整階段后才啟動，這一點應(yīng)該是可以簡單理解的，因為數(shù)據(jù)規(guī)整前的數(shù)據(jù)不用作割接后投產(chǎn)，沒有校驗價值。而在前面數(shù)據(jù)校驗章節(jié)中提到，數(shù)據(jù)校驗分為兩種，一種是sync_diff_inspector這類實體數(shù)據(jù)校驗，另一種是select max（id）這類元數(shù)據(jù)校驗，兩種方法并不沖突，在實際任務(wù)中可以靈活安排來減少對割接時間窗口的壓力。

　　以近期XX公司遷移到UCloud項目為例，割接時間只有凌晨12點到早上6點的6個小時，中間需要進(jìn)行應(yīng)用配置和業(yè)務(wù)測試，留給數(shù)據(jù)校驗的時間不多，所以早在數(shù)據(jù)割接之前就啟動了sync_diff_inspector對實體數(shù)據(jù)進(jìn)行校驗。結(jié)果數(shù)據(jù)校驗時間和效果都如前預(yù)料，最大一個500G數(shù)據(jù)庫的實體數(shù)據(jù)校驗花費了1天多的時間，同時多個數(shù)據(jù)庫的校驗也發(fā)現(xiàn)了少量的不一致，這一部分不一致經(jīng)過人工對比后發(fā)現(xiàn)實際一致。隨后在割接過程中進(jìn)行元數(shù)據(jù)校驗，結(jié)果隨著消息隊列完成消費和定時任務(wù)結(jié)束，兩邊的select max（id）或者select count（id）結(jié)果最終一致了。

　　在割接階段，不得不考慮的一個問題就是回滾，在割接過程中發(fā)現(xiàn)數(shù)據(jù)確實出現(xiàn)了不一致，這時就需要對不一致的范圍做合理的評估。如果在割接時間窗口中的元數(shù)據(jù)校驗如果發(fā)現(xiàn)不一致，這時候最明智的處理手段就是回滾，而保障原平臺沒有臟數(shù)據(jù)則是回滾的基礎(chǔ)。

　　以xx公司遷移到UCloud為例，在托管IDC遷移到UCloud混合云的過程中，由于業(yè)務(wù)依賴較少，所以采用了可以敏捷割接和回滾的業(yè)務(wù)模塊遷移方式。在這一案例的割接實踐中，運維團(tuán)隊不僅為數(shù)據(jù)庫設(shè)置了只讀，而且也在業(yè)務(wù)應(yīng)用中嵌入了只讀開關(guān)，只要通過配置中心發(fā)布開啟只讀開關(guān)即可生效。在數(shù)據(jù)庫只讀后就參考數(shù)據(jù)同步階段的數(shù)據(jù)校驗方式，對數(shù)據(jù)或者元數(shù)據(jù)進(jìn)行校驗，最后在確認(rèn)應(yīng)用的讀取功能都正常以后再解除目標(biāo)庫的只讀，并開放業(yè)務(wù)。在這個案例中回滾也是相對簡單的，如果發(fā)現(xiàn)應(yīng)用的讀取功能異常，這時候只需將應(yīng)用重新部署回原平臺，啟動和解除數(shù)據(jù)庫只讀即可。

　　而對于需要進(jìn)行整體割接的任務(wù)，割接過程相比于模塊化的割接會復(fù)雜一些，但是與模塊化割接的機(jī)理大同小異。在割接過程中先通過停用負(fù)載均衡、設(shè)置ACL的方式停止業(yè)務(wù)入口，等待消息隊列完成消費數(shù)據(jù)落地以及定時任務(wù)運行完成，然后參考割接準(zhǔn)備階段的方法對原平臺數(shù)據(jù)進(jìn)行保護(hù)。在完成原平臺的數(shù)據(jù)封存后，需要等待同步任務(wù)最終完成同步以及對數(shù)據(jù)進(jìn)行校驗，具體的數(shù)據(jù)校驗方法是參考前文中數(shù)據(jù)校驗方法完成的。在確認(rèn)兩邊平臺數(shù)據(jù)一致后，就可以停止同步，在新平臺啟動應(yīng)用和進(jìn)行內(nèi)部測試。

　　至于回滾操作，本身也是有時間邊界的，當(dāng)新平臺業(yè)務(wù)入口做了灰度開放后就不能進(jìn)行回滾操作了，因為這時候有很大機(jī)率真正的客戶數(shù)據(jù)已經(jīng)寫入到新平臺，但是這部分新數(shù)據(jù)又沒有同步回原平臺，這樣兩邊數(shù)據(jù)就是不一致的。但是一般而言，只要保證遷移兩邊平臺數(shù)據(jù)是一致的，應(yīng)用程序大多是應(yīng)用狀態(tài)或者代碼邏輯問題，相對可控。

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

　　以上就是UCloud華南架構(gòu)團(tuán)隊關(guān)于跨云遷移在數(shù)據(jù)同步、規(guī)整和割接過程中保障數(shù)據(jù)一致性的一些實踐和思考，希望對遇到同類問題的大家有所幫助。當(dāng)然，本文所闡述的數(shù)據(jù)遷移同步的解決方案也適用于本地IDC遷移上云的場景。