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

前言

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

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

1. 數據完整性和一致性挑戰(zhàn)。
2. 時效性，即遷移窗口期相對有限。
3. 應用依賴性和各種調用關系。

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

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

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

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

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

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

MySQL同步

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

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

【案例】

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

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

數據同步

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

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

數據校驗

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

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

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

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

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

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

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

文件存儲同步

文件同步

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

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

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

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

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

實際生產環(huán)境中的fastdfs binlog

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

文件校驗

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

要解決靜默錯誤的唯一辦法是全鏈路數據校驗：

• 在數據上傳前，確認數據正常，生成校驗和；
• 上傳到某個存儲服務之后，存儲服務存儲文件并且記錄這個文件的校驗和；
• 定期對數據進行巡檢，重新計算文件校驗和并且和記錄值比較；
• 取出數據時，也對數據進行校驗和比較，這樣才能保證文件數據一致。

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

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

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

相應的，可以通過以下命令對遷移后的整個目錄進行遞歸遍歷校驗。

md5sum -c my.md5

對象存儲同步

數據同步

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

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

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

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

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

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

數據校驗

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

寫在最后

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

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