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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　當然也有一些實(shí)現了分布式鎖的文件系統，例如vmware的vmfs和oracle的ocfs，可以共享文件系統數據的同時(shí)，通過(guò)鎖機制來(lái)實(shí)現操作系統對文件變化的感知。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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