作者 | 向迪
來源 |
阿裡技術公衆号一 背景
容災系統的重要目标在于保證系統資料和服務的“連續性”。當系統發生故障時，容災系統能夠快速恢複服務和保證資料的有效性。為了防止天災人禍、不可抗力，在同城或異地建立對應的IT系統，其中最核心的工作是資料同步。
本文選取應用層容災的場景中，對于哪些資料表需要跨雲同步，哪些資料表不需要跨雲同步的問題進行探讨。通過一個具體的案例，幫助讀者更好地梳理同步表和過濾表的方法，以滿足應用層的業務容災需求。
二 相關術語
本文探讨的場景是基于阿裡雲建構的應用層容災，涉及到以下關鍵術語：
RDS MySQL：MySQL 版是全球最受歡迎的開源資料庫之一，作為開源軟體組合 LAMP（Linux + Apache + MySQL + Perl/PHP/Python） 中的重要一環，廣泛應用于各類應用場景。阿裡雲RDS MySQL版，通過深度的核心優化和獨享執行個體提供穩定極緻的資料庫性能，同時靈活的部署架構及産品形态，可滿足不同場景下的資料庫需求。
DTS：資料傳輸服務(Data Transmission Service) 支援關系型資料庫（MySQL等）、NoSQL、大資料(OLAP)等資料源間的資料傳輸。 它是一種集資料遷移、資料訂閱及資料實時同步于一體的資料傳輸服務。資料傳輸緻力于在公共雲、混合雲場景下，解決遠距離、毫秒級異步資料傳輸難題。 使用資料傳輸輕松建構安全、可擴充、高可用（容災）的資料架構。
ASR：ASR-DR（Apsara Stack Resilience Disaster Recovery）是一款提供容災功能的雲産品，支援RDS MySQL的容災管理。ASR是為了在災難發生時，快速地實作容災切換，盡可能地降低RTO，而開發的基于圖形互動的切換工具。
同步表：本文特指RDS MySQL的資料庫和資料表中，哪些表必須從一朵雲備份到另外一朵雲，即跨雲同步。
過濾表：本文特指RDS MySQL的資料庫和資料表中，哪些表不能或不需要，從一朵雲備份到另外一朵雲。
應用配置表：本文特指應用層在RDS MySQL中的資料表，這個表記錄應用層的相關配置資訊，比如IP、域名、定時任務的開關狀态等等。
Sequence：全局唯一序列号ID，在分布式系統裡面應用廣泛，可用于交易流水号，使用者ID等。 在搜尋, 存儲資料, 加快檢索速度等等很多方面都有着重要的意義。這個ID常常是資料庫的主鍵，要求全局唯一、支援高并發、容錯單點故障。為了提高性能，應用層通常每次從資料庫中擷取一批序列号（比如1萬個），存放到應用記憶體中使用，避免頻繁通路資料庫。記憶體中的序列号使用完成後，再次從資料庫中進行擷取新的一批序列号。
三 應用容災中關于過濾表的關鍵技術問題
為什麼需要梳理不做跨雲同步的過濾表？
非容災應用
- 備中心資源限制：實際項目中，受限于備中心的資源限制，無法在備中心内部署應用系統，是以非容災的應用對應的資料庫和資料表無需同步。
- 運維臨時備份庫和備份表無需同步：在日常運維中，DBA在對資料庫進行變更時，通常會做臨時性備份。臨時備份的資料庫或資料表，由于阿裡雲 RDS MySQL叢集本身已經在背景進行了備份，無需使用者再做一次跨雲同步。這樣可以減少同步鍊路的帶寬和容災切換的管理工作量。
- 不支援容災的應用：雲産品的容災能力建設是一個持續過程，某些雲産品在項目傳遞階段暫時還不具備容災能力，但是使用者的應用依賴了這些指定的雲産品。是以這部分的應用暫時無法做容災演練，對應的資料庫和資料表也可以暫時不做同步。待應用的全流程依賴的雲産品都支援容災後，再進行資料同步即可。
有差異的配置表
- 應用配置的方式：應用系統為了将代碼和配置分開管理，通常将配置參數單獨存放和管理。常見的配置形式有配置檔案、RDS MySQL資料庫、專用的配置中心，其中專用配置中心背景也用了RDS MySQL來存儲資料。比較忌諱的方式是在代碼中寫死配置參數，如IP、域名等。
- 環境參數：應用軟體在使用雲産品如RDS MySQL、OSS、SLB等産品時，需要通過IP、域名、賬号密碼、AK/SK進行連接配接。
- 應用參數：某些功能隻能在一個中心内的應用執行，這些功能開關在資料表裡面的某些字段值進行控制。比如某些定時任務，會定期和外部機構發生批處理的調用。如果雙中心的定時任務同時運作，可能會導緻外部機構的批處理重複執行，這依賴于外部機構能否支援重複執行相同的批處理任務。這些定時任務的配置表需要在雙中心分别配置。
- 同城容災的配置方式：第2點的環境參數預設是相同的。同城一朵雲的雙中心距離較近（小于100公裡），應用部署在一朵雲的兩個可用區，雲産品連接配接資訊是相同的。是以應用軟體在部署時，通路的是相同的環境參數。此場景中，需要梳理有差異的環境參數是比較少的。
- 異地容災的配置方式：第2點的環境參數存在差異。同城兩朵雲的雙中心距離較遠（大于100公裡），應用部署在兩朵雲的兩個可用區，雲産品連接配接資訊是不同的。是以應用軟體在部署時，通路的是不同的環境參數。此場景中，需要每個應用分别梳理差異的環境參數。差異的環境參數所在的資料表不能跨雲同步，否則會導緻應用系統部署失敗。
需要雙寫的業務表
- 雙寫的場景：a）業務流量在雙中心同時處理，稱為應用層雙活，需要同時向雙中心寫入資料表。b）應用運作期記錄微服務的調用日志等。理想情況下，應該是有業務流量在處理時，應用才會向資料庫中記錄資料。實際項目中，業務也會出現特殊情況，在備中心的應用，即使沒有流量請求，也會定期寫入一些日志，比如微服務調用日志、定時任務日志、應用啟動時更新全局唯一序列号Sequence等等。雙寫的場景，要求主中心和備中心的RDS MySQL都具備讀和寫權限。
- 同城雙活場景：同城一朵雲的雙活架構中，主中心和備中心對應用層提供統一的雲産品連接配接資訊，應用都具備向RDS MySQL的寫入權限。
- 異地主備場景：異地兩朵雲的主備架構中，主中心RDS MySQL對應用層提供讀寫權限，而備中心RDS MySQL向應用層提供隻讀權限。這種權限政策無法滿足第1點中的雙寫要求。是以對于雙寫的表，需要按照應用次元梳理過濾表。
如何梳理不做跨雲同步的資料表？
在項目中會發現，應用軟體開發商更關注業務邏輯的實作，對于雲産品使用的最佳實踐以及容災能力的了解程度，可能和我們的預期存在一定的差異。而梳理過濾表，主要由應用開發商來執行，在梳理過程中有幾個常見的問題。
- 設計和開發時期，開發人員應該如何做來減少容災時候不同步的過濾表？
- 部署和運維時期，運維人員應該從哪些角度來確定過濾表的完整性和正确性？
如果梳理錯誤，對應用層容災演練有什麼影響？
在項目中，往往受限于工期和生産系統穩定性運作的限制，應用開發商和雲平台廠商即便清楚設計和開發的最佳實踐，也比較難限時完成改造。是以部署和運維期的時候，梳理過濾表和準備應急預案，是容災演練的重點工作項。
我們來分析一下，如果梳理過濾表錯誤，可能對應用層容災有什麼影響？
對非容災應用的影響：
- 幾乎沒影響。前面分析過，建議非容災的應用可以不做資料備份，或者備中心應用在備份資料上不做為生産用途。
對容災應用的影響：
- 備中心部署應用後，啟動應用失敗，此時能夠識别出錯誤的環境參數。應對措施是停止對應資料表的同步，修正讀寫權限後繼續部署。
- 備中心應用在測試功能時，重點關注背景定時任務和非業務請求寫RDS MySQL的場景，在測試階段修正過濾表的清單。
- 對生産系統運作期做容災切換演練，在異地容災架構中，錯誤的過濾表清單可能會導緻資料庫主鍵寫沖突的錯誤，進而出現寫業務失敗問題。此時可通過應急預案，緊急停止或增加同步功能或修正資料表字段值，重新開機應用方式的手段來恢複。在下次演練前修正過濾表清單。本文後面将對此場景用一個案例簡單說明。
四 在應用容災中設計不同步的資料表
前面我們已經介紹了應用容災中哪些表不同步的必要性，本節我們來探讨如何梳理和設定過濾表。以下分析是比較理想的情況，實際項目中會有一些差别。
雲平台角度
- 了解雲平台的能力：目前主流的雲平台廠商都有RDS MySQL産品，但是每家廠商的RDS MySQL在同城多可用區和異地多Region中的容災能力是有差別的。使用者需要了解，每家雲廠商的資料同步能力，在同城和異地兩種情況下，是背景自動完成？還是利用工具（如阿裡雲的DTS）？還是人工寫腳本完成？
- 配置過濾表的方式：阿裡雲DTS産品支援在建立RDS MySQL執行個體同步鍊路時，配置哪些資料庫和資料表不同步。
- 自動配置過濾表功能：在容災演練過程中，會涉及主切備、備切主，是以對應資料同步方向發生反轉，我們稱成為正向同步和反向同步。當發生同步方向反轉時，需要容災切換平台支援自動配置過濾表。阿裡雲ASR-DR支援第一次建立同步鍊路時，儲存過濾表的清單，後續每次同步方向切換時，由ASR-DR自動給新的鍊路配置過濾表。
如下是阿裡雲資料資料傳輸服務DTS産品公開的資料文檔。
應用層角度
接下來我們從應用開發商比較關注點幾個階段，分析如何有效性地基于雲容災來傳遞應用軟體。
1.設計階段：
- 基于雲容災的設計思路。考慮應用未來會部署在兩朵雲或多朵雲，有可能是不同廠商的雲平台上。是以早期基于IOE架構的容災架構，由專業存儲硬體完成的資料層同步在多雲場景下将不适用，而Oracle昂貴的license也是很多企業難以接受的。
- 考慮為每朵雲和每個中心預留辨別參數，用于表示目前配置适用于哪朵雲上。由配置中心統一管理目前運作環境上是哪朵雲的參數生效，應用代碼無需關注自己運作在哪朵雲上。
- 識别哪些場景的功能隻能在其中一朵雲上運作的，并為這些功能安排開關。通過配置中心并将開關設定為可動态配置和生效。重點關注定時任務。
- 建議将這些功能開關的操作放在白屏界面，便于在容災切換有限而緊迫的時間内，允許運維人員快速操作，而不是打電話到處問人，關閉某個定時任務是在哪個庫、哪個表的哪個字段來控制開關。
- 記錄過濾表清單，并及時更新。
2.開發階段：
- 優先使用配置中心來儲存參數。實際項目中，儲存配置的方式有多種方式，包括配置中心、配置檔案、RDS MySQL、甚至還有在代碼中直接編碼某個位址、賬号密碼。阿裡雲EDAS産品提供配置中心功能，支援動态配置、靜态配置，以及配置變更後動态推送，而不需要應用重新開機才能生效。
- 配置中心本身的位址，可以記錄在應用的配置檔案中，将配置檔案和應用程式一起打包釋出。因為配置中心服務在部署後，很少會發生變化。
- 如果暫時無法使用配置中心，必須要用RDS MySQL來管理配置。建議将記錄不同雲環境參數的配置放在獨立的資料表中，單獨提供功能開關的配置也放在獨立的資料表中，不要和業務表耦合在一起。好處是降低了管理過濾表的難度。重點關注雲産品的域名、IP、賬号密碼、AK/SK。
3. 部署階段：
- 運維人員和開發人員，确認清楚每個過濾表的被選中的原因，背後的業務依據是什麼？重點關注是否多配了過濾表。
- 登陸每個資料庫，檢查容災切換平台ASR-DR是否按照預期來設定過濾表。當過濾表有上百個的時候，容易出現遺漏或錯誤。
- 創造條件在備中心上提前驗證業務功能，重點關注過濾表場景是否符合預期，關注定時任務是否隻在一個中心上運作。
4. 運維階段：
- 配置變更在兩朵雲上的過濾表同時執行。當在主中心上對過濾步表進行了變更後，如增加字段或調整字段類型，備中心無法感覺到，需要手工在備中心上做同樣的修改。否則容災切換到備中心後會因為表未更新導緻應用錯誤。
- 過濾表恢複為同步表。早期梳理過濾表清單有誤，多配置了過濾表，後來驗證需要同步。需要重新對資料表做全量資料同步，并在容災管理平台ASR-DR上修改這個表是否同步的标志。
- 同步表改為過濾表。早期同步的表，由于業務做了調整，後續無需再同步，需要在容災管理平台ASR-DR并在容災管理平台ASR-DR上修改這個表是否同步的标志。
下圖為異地容災主備架構下，同步表和過濾表的配置邏輯說明。
五 案例
下面分析一個異地容災的項目中，由于過濾表清單梳理錯誤，導緻業務異常問題及處理經驗，便于讀者對資料表是否需要跨雲同步更有體感。
（1）問題描述
在阿裡雲容災平台ASR-DR對某個應用執行容災切換（RDS MySQL讀寫權限從Cloud A切換至Cloud B）後，業務請求在備中心（Cloud B）時，業務報錯，資料庫提示“主鍵沖突”。
（2）問題分析
我們根據問題處理的先後順序，對問題定位過程進行分析。
1. 分析資料庫報錯“主鍵沖突”：
- 确認沖突的字段值為交易流水号ID。檢查業務資料表，确認這個ID的交易資訊已經存在。
2. 分析業務請求路徑：
- 分析是否接入層流量排程異常導緻的雙寫。在異地容災的主備架構中，通過接入層的全局負載均衡裝置GSLB控制，保證隻有主中心有業務請求流量，備中心沒有業務請求流量。是以雙中心業務雙寫導緻的主鍵沖突的嫌疑可以排除掉。
- 分析是否為主中心應用層緩存在主備切換後延遲寫入資料。在主備架構中，容災平台ASR-DR平台會保證主中心的RDS MySQL資料庫權限設定為隻讀後，才會對備中心的應用開放對RDS MySQL的讀寫權限。即使主中心的應用層有緩存延遲寫入，在容災切換後，主中心應用沒有權限寫入資料，不會出現雙寫場景。排除此嫌疑。
- 分析是否為容災切換前已使用了該序列号。登陸主中心的資料庫，檢查序列号字段目前可用範圍是[90000000000, 18446744073709551615]，說明小于90000000000的序列号已經被使用。而目前提示主鍵沖突的序列号80000000000已經在業務表中有對應的交易記錄。是以确認這個交易記錄号是在主中心使用過了。
- 分析備中心應用擷取序列号的記錄。從應用日志看到，備中心應用在首次啟動時，擷取了一次最新的序列号，後面沒有再從資料庫擷取最新的序列号。同時檢查應用的記憶體值，發現備中心目前正在使用序列号範圍[80000000000, 80000009999]。顯然這是過期的序列号。
問題結論：備中心應用使用了過期的交易流水号ID，導緻的寫資料庫出現“主鍵沖突”。
3. 分析問題引入過程：
- 分析應用擷取序列号的流程：應用首次啟動時，從資料庫中擷取1萬個可用的序列号，并更新資料庫和應用的記憶體值。
- 分析主備中心上的資料同步機制：作為管理全局唯一性序列号的資料表xx_table，通過資料同步工具DTS能夠保證資料實時在雙中心之間同步，且應用在更新資料庫序列号時，對資料庫加鎖防止不一緻。理論上不會出現主備中心上擷取到相同的序列号。
- 分析主備中心上資料表xx_table内容是否一緻：發現主中心上的序列号可用範圍是[90000000000, 18446744073709551615]，而備中心的序列号可用範圍是[80000010000, 18446744073709551615]。兩者并不一緻，說明資料表并沒有同步。
- 檢查資料同步工具DTS：工作正常，未發現任何錯誤或故障。
- 檢查過濾表清單：管理全局唯一性序列号的資料表xx_table應該跨雲同步，但是卻被配置為過濾表，導緻了資料無法同步。
- 檢查過濾表的梳理過程：在容災演練前的準備階段，運維人員在備中心部署應用後，業務人員驗證功能交易失敗。失敗原因是應用啟動時擷取序列号後寫資料庫失敗，提示無寫權限，是以交易功能初始化失敗。在主備架構下，預設主中心應用對RDS MySQL有讀寫權限，備中心對RDS MySQL有隻讀權限。而備中心啟動時需要些權限，是以業務人員将管理全局唯一性序列号的資料表xx_table加入到了不同步的過濾表清單中，導緻這張表沒有從主中心同步到備中心。
問題結論：管理全局唯一性序列号的資料表xx_table被錯誤地加入到了不做跨雲同步的過濾表清單
應急措施
- 手動将備中心的資料表xx_table中的序列号有效範圍，修正為正确的[90000000000, 18446744073709551615]。
- 重新開機備中心的應用軟體，觸發應用重新擷取序列号。
改進措施
- 同步資料：管理全局唯一性序列号的資料表xx_table需要同步，從過濾表清單中移除xx_table，確定主備中心的有效序列号範圍一緻。
- 應用改造：當備中心對RDS MySQL有隻讀權限時，允許更新序列号失敗，應用初始化成功。當容災切換後，備中心獲得RDS MySQ讀寫權限後，由業務請求觸發重新按需擷取最新的序列号。
- 測試效果：
- 主中心和備中心同步資料完成後，斷開同步鍊路，手動設定備中心資料庫為隻讀。
- 重新部署改造後的應用，在隻讀模式下，驗證應用啟動成功，并且業務請求失敗（符合預期）。
- 手動設定備中心資料庫為讀寫，業務請求成功，檢查應用是否成功重新擷取到有效序列号。
- 重新配置主中心和備中心資料同步鍊路。
- 容災演練：再次進行演練來驗證全業務場景。
改進前
改進後
六 小結
- 容災演練是發現系統性問題的起點，不是終點，需要定期開展演練來保鮮系統的容災能力。
- 雲平台容災不等于應用容災，應用級容災是系統性工程。
- 通過演練來檢查工程能力，技術上包括雲平台、應用和網絡；流程上包括故障判斷、容災決策、切換操作、應急預案等。
七 誠邀有志之士
阿裡雲的兩地三中心、異地多活等高可用架構通過了多年雙十一大促的考驗。目前阿裡雲向全球使用者開放這些高可用架構的技術紅利，幫助使用者的IT系統更健壯。歡迎有志人士加入我們，有興趣的同學可以投遞履歷到[email protected]