摘要：另外對于需要盡量減少應用重啟的系統也可以優先考慮這種方式來保障數據一致性。只需要保證這三類程序都是停止的，那么就可以保證沒有同步服務以外的程序對數據進行修改，從而保障數據一致性。

在《跨云遷移過程中的數據同步及一致性校驗實踐（一）》中我們主要介紹了跨云遷移中數據同步階段的存儲組件MySQL、文件存儲和對象存儲的數據遷移過程，本文將重點圍繞跨云遷移的數據規整階段(清理測試時產生的臟數據)和數據割接階段的技術細節進行解析。

數據規整階段

1、臟數據處理

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

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

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

2、保障數據一致性

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

基于用戶的數據庫只讀

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

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

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

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

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

結束應用進程

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

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

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

總結來說，結束應用程序的方式適合應用可以各自獨立啟停，且生產環境應用、腳本和數據庫定時任務都完全統計清楚明確的情況下使用。

ACL網絡隔離

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

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

經過對上面三種保障數據一致性方法的對比，可以發現這三種方法其實并沒有相互沖突的點，在實際中我們可以靈活組合來匹配更多業務環境的要求，例如同時使用結束應用進程和ACL網絡隔離。

【案例】

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

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

數據割接階段

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

1、數據校驗時機

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

【案例】

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

2、割接與回滾

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

【案例】

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

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

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

總結

以上就是筆者關于跨云遷移在數據同步、規整和割接過程中保障數據一致性的一些實踐和思考，希望對遇到同類問題的大家有所幫助。當然，本文所闡述的數據遷移同步的解決方案也適用于本地IDC遷移上云的場景。