MySQL數據表應用容災中的方法是什么

本篇內容主要講解“MySQL數據表應用容災中的方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL數據表應用容災中的方法是什么”吧!

一 背景

容災系統的重要目標在于保證系統數據和服務的“連續性”。當系統發生故障時，容災系統能夠快速恢復服務和保證數據的有效性。為了防止天災人禍、不可抗力，在同城或異地建立對應的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讀寫權限后，由業務請求觸發重新按需獲取最新的序列號。

• 測試效果：主中心和備中心同步數據完成后，斷開同步鏈路，手動設置備中心數據庫為只讀。重新部署改造后的應用，在只讀模式下，驗證應用啟動成功，并且業務請求失敗（符合預期）。手動設置備中心數據庫為讀寫，業務請求成功，檢查應用是否成功重新獲取到有效序列號。重新配置主中心和備中心數據同步鏈路。

• 容災演練：再次進行演練來驗證全業務場景。

改進前

改進后

到此，相信大家對“MySQL數據表應用容災中的方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！