MySQL數(shù)據(jù)表應(yīng)用容災(zāi)中的方法是什么

本篇內(nèi)容主要講解“MySQL數(shù)據(jù)表應(yīng)用容災(zāi)中的方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“MySQL數(shù)據(jù)表應(yīng)用容災(zāi)中的方法是什么”吧!

一 背景

容災(zāi)系統(tǒng)的重要目標(biāo)在于保證系統(tǒng)數(shù)據(jù)和服務(wù)的“連續(xù)性”。當(dāng)系統(tǒng)發(fā)生故障時(shí)，容災(zāi)系統(tǒng)能夠快速恢復(fù)服務(wù)和保證數(shù)據(jù)的有效性。為了防止天災(zāi)人禍、不可抗力，在同城或異地建立對應(yīng)的IT系統(tǒng)，其中最核心的工作是數(shù)據(jù)同步。

本文選取應(yīng)用層容災(zāi)的場景中，對于哪些數(shù)據(jù)表需要跨云同步，哪些數(shù)據(jù)表不需要跨云同步的問題進(jìn)行探討。通過一個(gè)具體的案例，幫助讀者更好地梳理同步表和過濾表的方法，以滿足應(yīng)用層的業(yè)務(wù)容災(zāi)需求。

二 相關(guān)術(shù)語

本文探討的場景是基于阿里云構(gòu)建的應(yīng)用層容災(zāi)，涉及到以下關(guān)鍵術(shù)語：
RDS MySQL：MySQL 版是全球最受歡迎的開源數(shù)據(jù)庫之一，作為開源軟件組合 LAMP（Linux + Apache + MySQL + Perl/PHP/Python） 中的重要一環(huán)，廣泛應(yīng)用于各類應(yīng)用場景。阿里云RDS MySQL版，通過深度的內(nèi)核優(yōu)化和獨(dú)享實(shí)例提供穩(wěn)定極致的數(shù)據(jù)庫性能，同時(shí)靈活的部署架構(gòu)及產(chǎn)品形態(tài)，可滿足不同場景下的數(shù)據(jù)庫需求。

DTS：數(shù)據(jù)傳輸服務(wù)(Data Transmission Service) 支持關(guān)系型數(shù)據(jù)庫（MySQL等）、NoSQL、大數(shù)據(jù)(OLAP)等數(shù)據(jù)源間的數(shù)據(jù)傳輸。 它是一種集數(shù)據(jù)遷移、數(shù)據(jù)訂閱及數(shù)據(jù)實(shí)時(shí)同步于一體的數(shù)據(jù)傳輸服務(wù)。數(shù)據(jù)傳輸致力于在公共云、混合云場景下，解決遠(yuǎn)距離、毫秒級異步數(shù)據(jù)傳輸難題。 使用數(shù)據(jù)傳輸輕松構(gòu)建安全、可擴(kuò)展、高可用（容災(zāi)）的數(shù)據(jù)架構(gòu)。

ASR：ASR-DR（Apsara Stack Resilience Disaster Recovery）是一款提供容災(zāi)功能的云產(chǎn)品，支持RDS MySQL的容災(zāi)管理。ASR是為了在災(zāi)難發(fā)生時(shí)，快速地實(shí)現(xiàn)容災(zāi)切換，盡可能地降低RTO，而開發(fā)的基于圖形交互的切換工具。

同步表：本文特指RDS MySQL的數(shù)據(jù)庫和數(shù)據(jù)表中，哪些表必須從一朵云備份到另外一朵云，即跨云同步。

過濾表：本文特指RDS MySQL的數(shù)據(jù)庫和數(shù)據(jù)表中，哪些表不能或不需要，從一朵云備份到另外一朵云。

應(yīng)用配置表：本文特指應(yīng)用層在RDS MySQL中的數(shù)據(jù)表，這個(gè)表記錄應(yīng)用層的相關(guān)配置信息，比如IP、域名、定時(shí)任務(wù)的開關(guān)狀態(tài)等等。

Sequence：全局唯一序列號ID，在分布式系統(tǒng)里面應(yīng)用廣泛，可用于交易流水號，用戶ID等。 在搜索, 存儲數(shù)據(jù), 加快檢索速度等等很多方面都有著重要的意義。這個(gè)ID常常是數(shù)據(jù)庫的主鍵，要求全局唯一、支持高并發(fā)、容錯單點(diǎn)故障。為了提高性能，應(yīng)用層通常每次從數(shù)據(jù)庫中獲取一批序列號（比如1萬個(gè)），存放到應(yīng)用內(nèi)存中使用，避免頻繁訪問數(shù)據(jù)庫。內(nèi)存中的序列號使用完成后，再次從數(shù)據(jù)庫中進(jìn)行獲取新的一批序列號。

三 應(yīng)用容災(zāi)中關(guān)于過濾表的關(guān)鍵技術(shù)問題

為什么需要梳理不做跨云同步的過濾表？

非容災(zāi)應(yīng)用

• 備中心資源限制：實(shí)際項(xiàng)目中，受限于備中心的資源限制，無法在備中心內(nèi)部署應(yīng)用系統(tǒng)，因此非容災(zāi)的應(yīng)用對應(yīng)的數(shù)據(jù)庫和數(shù)據(jù)表無需同步。

• 運(yùn)維臨時(shí)備份庫和備份表無需同步：在日常運(yùn)維中，DBA在對數(shù)據(jù)庫進(jìn)行變更時(shí)，通常會做臨時(shí)性備份。臨時(shí)備份的數(shù)據(jù)庫或數(shù)據(jù)表，由于阿里云 RDS MySQL集群本身已經(jīng)在后臺進(jìn)行了備份，無需用戶再做一次跨云同步。這樣可以減少同步鏈路的帶寬和容災(zāi)切換的管理工作量。

• 不支持容災(zāi)的應(yīng)用：云產(chǎn)品的容災(zāi)能力建設(shè)是一個(gè)持續(xù)過程，某些云產(chǎn)品在項(xiàng)目交付階段暫時(shí)還不具備容災(zāi)能力，但是用戶的應(yīng)用依賴了這些指定的云產(chǎn)品。因此這部分的應(yīng)用暫時(shí)無法做容災(zāi)演練，對應(yīng)的數(shù)據(jù)庫和數(shù)據(jù)表也可以暫時(shí)不做同步。待應(yīng)用的全流程依賴的云產(chǎn)品都支持容災(zāi)后，再進(jìn)行數(shù)據(jù)同步即可。

有差異的配置表

• 應(yīng)用配置的方式：應(yīng)用系統(tǒng)為了將代碼和配置分開管理，通常將配置參數(shù)單獨(dú)存放和管理。常見的配置形式有配置文件、RDS MySQL數(shù)據(jù)庫、專用的配置中心，其中專用配置中心后臺也用了RDS MySQL來存儲數(shù)據(jù)。比較忌諱的方式是在代碼中硬編碼配置參數(shù)，如IP、域名等。

• 環(huán)境參數(shù)：應(yīng)用軟件在使用云產(chǎn)品如RDS MySQL、OSS、SLB等產(chǎn)品時(shí)，需要通過IP、域名、賬號密碼、AK/SK進(jìn)行連接。

• 應(yīng)用參數(shù)：某些功能只能在一個(gè)中心內(nèi)的應(yīng)用執(zhí)行，這些功能開關(guān)在數(shù)據(jù)表里面的某些字段值進(jìn)行控制。比如某些定時(shí)任務(wù)，會定期和外部機(jī)構(gòu)發(fā)生批處理的調(diào)用。如果雙中心的定時(shí)任務(wù)同時(shí)運(yùn)行，可能會導(dǎo)致外部機(jī)構(gòu)的批處理重復(fù)執(zhí)行，這依賴于外部機(jī)構(gòu)能否支持重復(fù)執(zhí)行相同的批處理任務(wù)。這些定時(shí)任務(wù)的配置表需要在雙中心分別配置。

• 同城容災(zāi)的配置方式：第2點(diǎn)的環(huán)境參數(shù)默認(rèn)是相同的。同城一朵云的雙中心距離較近（小于100公里），應(yīng)用部署在一朵云的兩個(gè)可用區(qū)，云產(chǎn)品連接信息是相同的。因此應(yīng)用軟件在部署時(shí)，訪問的是相同的環(huán)境參數(shù)。此場景中，需要梳理有差異的環(huán)境參數(shù)是比較少的。

• 異地容災(zāi)的配置方式：第2點(diǎn)的環(huán)境參數(shù)存在差異。同城兩朵云的雙中心距離較遠(yuǎn)（大于100公里），應(yīng)用部署在兩朵云的兩個(gè)可用區(qū)，云產(chǎn)品連接信息是不同的。因此應(yīng)用軟件在部署時(shí)，訪問的是不同的環(huán)境參數(shù)。此場景中，需要每個(gè)應(yīng)用分別梳理差異的環(huán)境參數(shù)。差異的環(huán)境參數(shù)所在的數(shù)據(jù)表不能跨云同步，否則會導(dǎo)致應(yīng)用系統(tǒng)部署失敗。

需要雙寫的業(yè)務(wù)表

• 雙寫的場景：a）業(yè)務(wù)流量在雙中心同時(shí)處理，稱為應(yīng)用層雙活，需要同時(shí)向雙中心寫入數(shù)據(jù)表。b）應(yīng)用運(yùn)行期記錄微服務(wù)的調(diào)用日志等。理想情況下，應(yīng)該是有業(yè)務(wù)流量在處理時(shí)，應(yīng)用才會向數(shù)據(jù)庫中記錄數(shù)據(jù)。實(shí)際項(xiàng)目中，業(yè)務(wù)也會出現(xiàn)特殊情況，在備中心的應(yīng)用，即使沒有流量請求，也會定期寫入一些日志，比如微服務(wù)調(diào)用日志、定時(shí)任務(wù)日志、應(yīng)用啟動時(shí)更新全局唯一序列號Sequence等等。雙寫的場景，要求主中心和備中心的RDS MySQL都具備讀和寫權(quán)限。

• 同城雙活場景：同城一朵云的雙活架構(gòu)中，主中心和備中心對應(yīng)用層提供統(tǒng)一的云產(chǎn)品連接信息，應(yīng)用都具備向RDS MySQL的寫入權(quán)限。

• 異地主備場景：異地兩朵云的主備架構(gòu)中，主中心RDS MySQL對應(yīng)用層提供讀寫權(quán)限，而備中心RDS MySQL向應(yīng)用層提供只讀權(quán)限。這種權(quán)限策略無法滿足第1點(diǎn)中的雙寫要求。因此對于雙寫的表，需要按照應(yīng)用維度梳理過濾表。

如何梳理不做跨云同步的數(shù)據(jù)表？

在項(xiàng)目中會發(fā)現(xiàn)，應(yīng)用軟件開發(fā)商更關(guān)注業(yè)務(wù)邏輯的實(shí)現(xiàn)，對于云產(chǎn)品使用的最佳實(shí)踐以及容災(zāi)能力的了解程度，可能和我們的預(yù)期存在一定的差異。而梳理過濾表，主要由應(yīng)用開發(fā)商來執(zhí)行，在梳理過程中有幾個(gè)常見的問題。

• 設(shè)計(jì)和開發(fā)時(shí)期，開發(fā)人員應(yīng)該如何做來減少容災(zāi)時(shí)候不同步的過濾表？

• 部署和運(yùn)維時(shí)期，運(yùn)維人員應(yīng)該從哪些角度來確保過濾表的完整性和正確性？

如果梳理錯誤，對應(yīng)用層容災(zāi)演練有什么影響？

在項(xiàng)目中，往往受限于工期和生產(chǎn)系統(tǒng)穩(wěn)定性運(yùn)行的約束，應(yīng)用開發(fā)商和云平臺廠商即便清楚設(shè)計(jì)和開發(fā)的最佳實(shí)踐，也比較難限時(shí)完成改造。因此部署和運(yùn)維期的時(shí)候，梳理過濾表和準(zhǔn)備應(yīng)急預(yù)案，是容災(zāi)演練的重點(diǎn)工作項(xiàng)。

我們來分析一下，如果梳理過濾表錯誤，可能對應(yīng)用層容災(zāi)有什么影響？
對非容災(zāi)應(yīng)用的影響：

• 幾乎沒影響。前面分析過，建議非容災(zāi)的應(yīng)用可以不做數(shù)據(jù)備份，或者備中心應(yīng)用在備份數(shù)據(jù)上不做為生產(chǎn)用途。

對容災(zāi)應(yīng)用的影響：

• 備中心部署應(yīng)用后，啟動應(yīng)用失敗，此時(shí)能夠識別出錯誤的環(huán)境參數(shù)。應(yīng)對措施是停止對應(yīng)數(shù)據(jù)表的同步，修正讀寫權(quán)限后繼續(xù)部署。

• 備中心應(yīng)用在測試功能時(shí)，重點(diǎn)關(guān)注后臺定時(shí)任務(wù)和非業(yè)務(wù)請求寫RDS MySQL的場景，在測試階段修正過濾表的清單。

• 對生產(chǎn)系統(tǒng)運(yùn)行期做容災(zāi)切換演練，在異地容災(zāi)架構(gòu)中，錯誤的過濾表清單可能會導(dǎo)致數(shù)據(jù)庫主鍵寫沖突的錯誤，進(jìn)而出現(xiàn)寫業(yè)務(wù)失敗問題。此時(shí)可通過應(yīng)急預(yù)案，緊急停止或增加同步功能或修正數(shù)據(jù)表字段值，重啟應(yīng)用方式的手段來恢復(fù)。在下次演練前修正過濾表清單。本文后面將對此場景用一個(gè)案例簡單說明。

四 在應(yīng)用容災(zāi)中設(shè)計(jì)不同步的數(shù)據(jù)表

前面我們已經(jīng)介紹了應(yīng)用容災(zāi)中哪些表不同步的必要性，本節(jié)我們來探討如何梳理和設(shè)置過濾表。以下分析是比較理想的情況，實(shí)際項(xiàng)目中會有一些差別。
云平臺角度

• 了解云平臺的能力：目前主流的云平臺廠商都有RDS MySQL產(chǎn)品，但是每家廠商的RDS MySQL在同城多可用區(qū)和異地多Region中的容災(zāi)能力是有區(qū)別的。用戶需要了解，每家云廠商的數(shù)據(jù)同步能力，在同城和異地兩種情況下，是后臺自動完成？還是利用工具（如阿里云的DTS）？還是人工寫腳本完成？

• 配置過濾表的方式：阿里云DTS產(chǎn)品支持在創(chuàng)建RDS MySQL實(shí)例同步鏈路時(shí)，配置哪些數(shù)據(jù)庫和數(shù)據(jù)表不同步。

• 自動配置過濾表功能：在容災(zāi)演練過程中，會涉及主切備、備切主，因此對應(yīng)數(shù)據(jù)同步方向發(fā)生反轉(zhuǎn)，我們稱成為正向同步和反向同步。當(dāng)發(fā)生同步方向反轉(zhuǎn)時(shí)，需要容災(zāi)切換平臺支持自動配置過濾表。阿里云ASR-DR支持第一次創(chuàng)建同步鏈路時(shí)，保存過濾表的清單，后續(xù)每次同步方向切換時(shí)，由ASR-DR自動給新的鏈路配置過濾表。

如下是阿里云數(shù)據(jù)數(shù)據(jù)傳輸服務(wù)DTS產(chǎn)品公開的資料文檔。

應(yīng)用層角度
接下來我們從應(yīng)用開發(fā)商比較關(guān)注點(diǎn)幾個(gè)階段，分析如何有效性地基于云容災(zāi)來交付應(yīng)用軟件。
1.設(shè)計(jì)階段：

• 基于云容災(zāi)的設(shè)計(jì)思路?？紤]應(yīng)用未來會部署在兩朵云或多朵云，有可能是不同廠商的云平臺上。因此早期基于IOE架構(gòu)的容災(zāi)架構(gòu)，由專業(yè)存儲硬件完成的數(shù)據(jù)層同步在多云場景下將不適用，而Oracle昂貴的license也是很多企業(yè)難以接受的。

• 考慮為每朵云和每個(gè)中心預(yù)留標(biāo)識參數(shù)，用于表示當(dāng)前配置適用于哪朵云上。由配置中心統(tǒng)一管理當(dāng)前運(yùn)行環(huán)境上是哪朵云的參數(shù)生效，應(yīng)用代碼無需關(guān)注自己運(yùn)行在哪朵云上。

• 識別哪些場景的功能只能在其中一朵云上運(yùn)行的，并為這些功能安排開關(guān)。通過配置中心并將開關(guān)設(shè)置為可動態(tài)配置和生效。重點(diǎn)關(guān)注定時(shí)任務(wù)。

• 建議將這些功能開關(guān)的操作放在白屏界面，便于在容災(zāi)切換有限而緊迫的時(shí)間內(nèi)，允許運(yùn)維人員快速操作，而不是打電話到處問人，關(guān)閉某個(gè)定時(shí)任務(wù)是在哪個(gè)庫、哪個(gè)表的哪個(gè)字段來控制開關(guān)。

• 記錄過濾表清單，并及時(shí)更新。

2.開發(fā)階段：

• 優(yōu)先使用配置中心來保存參數(shù)。實(shí)際項(xiàng)目中，保存配置的方式有多種方式，包括配置中心、配置文件、RDS MySQL、甚至還有在代碼中直接編碼某個(gè)地址、賬號密碼。阿里云EDAS產(chǎn)品提供配置中心功能，支持動態(tài)配置、靜態(tài)配置，以及配置變更后動態(tài)推送，而不需要應(yīng)用重啟才能生效。

• 配置中心本身的地址，可以記錄在應(yīng)用的配置文件中，將配置文件和應(yīng)用程序一起打包發(fā)布。因?yàn)榕渲弥行姆?wù)在部署后，很少會發(fā)生變化。

• 如果暫時(shí)無法使用配置中心，必須要用RDS MySQL來管理配置。建議將記錄不同云環(huán)境參數(shù)的配置放在獨(dú)立的數(shù)據(jù)表中，單獨(dú)提供功能開關(guān)的配置也放在獨(dú)立的數(shù)據(jù)表中，不要和業(yè)務(wù)表耦合在一起。好處是降低了管理過濾表的難度。重點(diǎn)關(guān)注云產(chǎn)品的域名、IP、賬號密碼、AK/SK。

3. 部署階段：

• 運(yùn)維人員和開發(fā)人員，確認(rèn)清楚每個(gè)過濾表的被選中的原因，背后的業(yè)務(wù)依據(jù)是什么？重點(diǎn)關(guān)注是否多配了過濾表。

• 登陸每個(gè)數(shù)據(jù)庫，檢查容災(zāi)切換平臺ASR-DR是否按照預(yù)期來設(shè)置過濾表。當(dāng)過濾表有上百個(gè)的時(shí)候，容易出現(xiàn)遺漏或錯誤。

• 創(chuàng)造條件在備中心上提前驗(yàn)證業(yè)務(wù)功能，重點(diǎn)關(guān)注過濾表場景是否符合預(yù)期，關(guān)注定時(shí)任務(wù)是否只在一個(gè)中心上運(yùn)行。

4. 運(yùn)維階段：

• 配置變更在兩朵云上的過濾表同時(shí)執(zhí)行。當(dāng)在主中心上對過濾步表進(jìn)行了變更后，如增加字段或調(diào)整字段類型，備中心無法感知到，需要手工在備中心上做同樣的修改。否則容災(zāi)切換到備中心后會因?yàn)楸砦锤聦?dǎo)致應(yīng)用錯誤。

• 過濾表恢復(fù)為同步表。早期梳理過濾表清單有誤，多配置了過濾表，后來驗(yàn)證需要同步。需要重新對數(shù)據(jù)表做全量數(shù)據(jù)同步，并在容災(zāi)管理平臺ASR-DR上修改這個(gè)表是否同步的標(biāo)志。

• 同步表改為過濾表。早期同步的表，由于業(yè)務(wù)做了調(diào)整，后續(xù)無需再同步，需要在容災(zāi)管理平臺ASR-DR并在容災(zāi)管理平臺ASR-DR上修改這個(gè)表是否同步的標(biāo)志。

下圖為異地容災(zāi)主備架構(gòu)下，同步表和過濾表的配置邏輯說明。

五 案例

下面分析一個(gè)異地容災(zāi)的項(xiàng)目中，由于過濾表清單梳理錯誤，導(dǎo)致業(yè)務(wù)異常問題及處理經(jīng)驗(yàn)，便于讀者對數(shù)據(jù)表是否需要跨云同步更有體感。

（1）問題描述
在阿里云容災(zāi)平臺ASR-DR對某個(gè)應(yīng)用執(zhí)行容災(zāi)切換（RDS MySQL讀寫權(quán)限從Cloud A切換至Cloud B）后，業(yè)務(wù)請求在備中心（Cloud B）時(shí)，業(yè)務(wù)報(bào)錯，數(shù)據(jù)庫提示“主鍵沖突”。

（2）問題分析
我們根據(jù)問題處理的先后順序，對問題定位過程進(jìn)行分析。

1. 分析數(shù)據(jù)庫報(bào)錯“主鍵沖突”：

• 確認(rèn)沖突的字段值為交易流水號ID。檢查業(yè)務(wù)數(shù)據(jù)表，確認(rèn)這個(gè)ID的交易信息已經(jīng)存在。

2. 分析業(yè)務(wù)請求路徑：

• 分析是否接入層流量調(diào)度異常導(dǎo)致的雙寫。在異地容災(zāi)的主備架構(gòu)中，通過接入層的全局負(fù)載均衡設(shè)備GSLB控制，保證只有主中心有業(yè)務(wù)請求流量，備中心沒有業(yè)務(wù)請求流量。因此雙中心業(yè)務(wù)雙寫導(dǎo)致的主鍵沖突的嫌疑可以排除掉。

• 分析是否為主中心應(yīng)用層緩存在主備切換后延遲寫入數(shù)據(jù)。在主備架構(gòu)中，容災(zāi)平臺ASR-DR平臺會保證主中心的RDS MySQL數(shù)據(jù)庫權(quán)限設(shè)置為只讀后，才會對備中心的應(yīng)用開放對RDS MySQL的讀寫權(quán)限。即使主中心的應(yīng)用層有緩存延遲寫入，在容災(zāi)切換后，主中心應(yīng)用沒有權(quán)限寫入數(shù)據(jù)，不會出現(xiàn)雙寫場景。排除此嫌疑。

• 分析是否為容災(zāi)切換前已使用了該序列號。登陸主中心的數(shù)據(jù)庫，檢查序列號字段當(dāng)前可用范圍是[90000000000, 18446744073709551615]，說明小于90000000000的序列號已經(jīng)被使用。而當(dāng)前提示主鍵沖突的序列號80000000000已經(jīng)在業(yè)務(wù)表中有對應(yīng)的交易記錄。因此確認(rèn)這個(gè)交易記錄號是在主中心使用過了。

• 分析備中心應(yīng)用獲取序列號的記錄。從應(yīng)用日志看到，備中心應(yīng)用在首次啟動時(shí)，獲取了一次最新的序列號，后面沒有再從數(shù)據(jù)庫獲取最新的序列號。同時(shí)檢查應(yīng)用的內(nèi)存值，發(fā)現(xiàn)備中心當(dāng)前正在使用序列號范圍[80000000000, 80000009999]。顯然這是過期的序列號。

問題結(jié)論：備中心應(yīng)用使用了過期的交易流水號ID，導(dǎo)致的寫數(shù)據(jù)庫出現(xiàn)“主鍵沖突”。

3. 分析問題引入過程：

• 分析應(yīng)用獲取序列號的流程：應(yīng)用首次啟動時(shí)，從數(shù)據(jù)庫中獲取1萬個(gè)可用的序列號，并更新數(shù)據(jù)庫和應(yīng)用的內(nèi)存值。

• 分析主備中心上的數(shù)據(jù)同步機(jī)制：作為管理全局唯一性序列號的數(shù)據(jù)表xx_table，通過數(shù)據(jù)同步工具DTS能夠保證數(shù)據(jù)實(shí)時(shí)在雙中心之間同步，且應(yīng)用在更新數(shù)據(jù)庫序列號時(shí)，對數(shù)據(jù)庫加鎖防止不一致。理論上不會出現(xiàn)主備中心上獲取到相同的序列號。

• 分析主備中心上數(shù)據(jù)表xx_table內(nèi)容是否一致：發(fā)現(xiàn)主中心上的序列號可用范圍是[90000000000, 18446744073709551615]，而備中心的序列號可用范圍是[80000010000, 18446744073709551615]。兩者并不一致，說明數(shù)據(jù)表并沒有同步。

• 檢查數(shù)據(jù)同步工具DTS：工作正常，未發(fā)現(xiàn)任何錯誤或故障。

• 檢查過濾表清單：管理全局唯一性序列號的數(shù)據(jù)表xx_table應(yīng)該跨云同步，但是卻被配置為過濾表，導(dǎo)致了數(shù)據(jù)無法同步。

• 檢查過濾表的梳理過程：在容災(zāi)演練前的準(zhǔn)備階段，運(yùn)維人員在備中心部署應(yīng)用后，業(yè)務(wù)人員驗(yàn)證功能交易失敗。失敗原因是應(yīng)用啟動時(shí)獲取序列號后寫數(shù)據(jù)庫失敗，提示無寫權(quán)限，因此交易功能初始化失敗。在主備架構(gòu)下，默認(rèn)主中心應(yīng)用對RDS MySQL有讀寫權(quán)限，備中心對RDS MySQL有只讀權(quán)限。而備中心啟動時(shí)需要些權(quán)限，因此業(yè)務(wù)人員將管理全局唯一性序列號的數(shù)據(jù)表xx_table加入到了不同步的過濾表清單中，導(dǎo)致這張表沒有從主中心同步到備中心。

問題結(jié)論：管理全局唯一性序列號的數(shù)據(jù)表xx_table被錯誤地加入到了不做跨云同步的過濾表清單

應(yīng)急措施

• 手動將備中心的數(shù)據(jù)表xx_table中的序列號有效范圍，修正為正確的[90000000000, 18446744073709551615]。

• 重啟備中心的應(yīng)用軟件，觸發(fā)應(yīng)用重新獲取序列號。

改進(jìn)措施

• 同步數(shù)據(jù)：管理全局唯一性序列號的數(shù)據(jù)表xx_table需要同步，從過濾表清單中移除xx_table，確保主備中心的有效序列號范圍一致。

• 應(yīng)用改造：當(dāng)備中心對RDS MySQL有只讀權(quán)限時(shí)，允許更新序列號失敗，應(yīng)用初始化成功。當(dāng)容災(zāi)切換后，備中心獲得RDS MySQ讀寫權(quán)限后，由業(yè)務(wù)請求觸發(fā)重新按需獲取最新的序列號。

• 測試效果：主中心和備中心同步數(shù)據(jù)完成后，斷開同步鏈路，手動設(shè)置備中心數(shù)據(jù)庫為只讀。重新部署改造后的應(yīng)用，在只讀模式下，驗(yàn)證應(yīng)用啟動成功，并且業(yè)務(wù)請求失?。ǚ项A(yù)期）。手動設(shè)置備中心數(shù)據(jù)庫為讀寫，業(yè)務(wù)請求成功，檢查應(yīng)用是否成功重新獲取到有效序列號。重新配置主中心和備中心數(shù)據(jù)同步鏈路。

• 容災(zāi)演練：再次進(jìn)行演練來驗(yàn)證全業(yè)務(wù)場景。

改進(jìn)前

改進(jìn)后

到此，相信大家對“MySQL數(shù)據(jù)表應(yīng)用容災(zāi)中的方法是什么”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！