一 背景
容災系統的重要目標在於保證系統數據和服務的“連續性”。當系統發生故障時，容災系統能夠快速恢復服務和保證數據的有效性。爲了防止天災人禍、不可抗力，在同城或異地建立對應的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讀寫權限後，由業務請求觸發重新按需獲取最新的序列號。
- 測試效果：
- 主中心和備中心同步數據完成後，斷開同步鏈路，手動設置備中心數據庫爲只讀。
- 重新部署改造後的應用，在只讀模式下，驗證應用啓動成功，並且業務請求失敗（符合預期）。
- 手動設置備中心數據庫爲讀寫，業務請求成功，檢查應用是否成功重新獲取到有效序列號。
- 重新配置主中心和備中心數據同步鏈路。
- 容災演練：再次進行演練來驗證全業務場景。
改進前
改進後
六 小結
- 容災演練是發現系統性問題的起點，不是終點，需要定期開展演練來保鮮系統的容災能力。
- 雲平臺容災不等於應用容災，應用級容災是系統性工程。
- 通過演練來檢查工程能力，技術上包括雲平臺、應用和網絡；流程上包括故障判斷、容災決策、切換操作、應急預案等。
本文爲阿里雲原創內容，未經允許不得轉載。