簡介： 容災(zāi)系統(tǒng)的重要目標(biāo)在于保證系統(tǒng)數(shù)據(jù)和服務(wù)的“連續(xù)性”。當(dāng)系統(tǒng)發(fā)生故障時，容災(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)行探討。通過一個具體的案例，幫助讀者更好地梳理同步表和過濾表的方法，以滿足應(yīng)用層的業(yè)務(wù)容災(zāi)需求。

?

一 背景

容災(zāi)系統(tǒng)的重要目標(biāo)在于保證系統(tǒng)數(shù)據(jù)和服務(wù)的“連續(xù)性”。當(dāng)系統(tǒng)發(fā)生故障時，容災(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)行探討。通過一個具體的案例，幫助讀者更好地梳理同步表和過濾表的方法，以滿足應(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ù)庫性能，同時靈活的部署架構(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ù)據(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í)現(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ù)表，這個表記錄應(yīng)用層的相關(guān)配置信息，比如IP、域名、定時任務(wù)的開關(guān)狀態(tài)等等。

Sequence：全局唯一序列號ID，在分布式系統(tǒng)里面應(yīng)用廣泛，可用于交易流水號，用戶ID等。 在搜索, 存儲數(shù)據(jù), 加快檢索速度等等很多方面都有著重要的意義。這個ID常常是數(shù)據(jù)庫的主鍵，要求全局唯一、支持高并發(fā)、容錯單點(diǎn)故障。為了提高性能，應(yīng)用層通常每次從數(shù)據(jù)庫中獲取一批序列號（比如1萬個），存放到應(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)維臨時備份庫和備份表無需同步：在日常運(yùn)維中，DBA在對數(shù)據(jù)庫進(jìn)行變更時，通常會做臨時性備份。臨時備份的數(shù)據(jù)庫或數(shù)據(jù)表，由于阿里云 RDS MySQL集群本身已經(jīng)在后臺進(jìn)行了備份，無需用戶再做一次跨云同步。這樣可以減少同步鏈路的帶寬和容災(zāi)切換的管理工作量。
• 不支持容災(zāi)的應(yīng)用：云產(chǎn)品的容災(zāi)能力建設(shè)是一個持續(xù)過程，某些云產(chǎn)品在項(xiàng)目交付階段暫時還不具備容災(zāi)能力，但是用戶的應(yīng)用依賴了這些指定的云產(chǎn)品。因此這部分的應(yīng)用暫時無法做容災(zāi)演練，對應(yīng)的數(shù)據(jù)庫和數(shù)據(jù)表也可以暫時不做同步。待應(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)品時，需要通過IP、域名、賬號密碼、AK/SK進(jìn)行連接。
• 應(yīng)用參數(shù)：某些功能只能在一個中心內(nèi)的應(yīng)用執(zhí)行，這些功能開關(guān)在數(shù)據(jù)表里面的某些字段值進(jìn)行控制。比如某些定時任務(wù)，會定期和外部機(jī)構(gòu)發(fā)生批處理的調(diào)用。如果雙中心的定時任務(wù)同時運(yùn)行，可能會導(dǎo)致外部機(jī)構(gòu)的批處理重復(fù)執(zhí)行，這依賴于外部機(jī)構(gòu)能否支持重復(fù)執(zhí)行相同的批處理任務(wù)。這些定時任務(wù)的配置表需要在雙中心分別配置。
• 同城容災(zāi)的配置方式：第2點(diǎn)的環(huán)境參數(shù)默認(rèn)是相同的。同城一朵云的雙中心距離較近（小于100公里），應(yīng)用部署在一朵云的兩個可用區(qū)，云產(chǎn)品連接信息是相同的。因此應(yīng)用軟件在部署時，訪問的是相同的環(huán)境參數(shù)。此場景中，需要梳理有差異的環(huán)境參數(shù)是比較少的。
• 異地容災(zāi)的配置方式：第2點(diǎn)的環(huán)境參數(shù)存在差異。同城兩朵云的雙中心距離較遠(yuǎn)（大于100公里），應(yīng)用部署在兩朵云的兩個可用區(qū)，云產(chǎn)品連接信息是不同的。因此應(yīng)用軟件在部署時，訪問的是不同的環(huán)境參數(shù)。此場景中，需要每個應(yīng)用分別梳理差異的環(huán)境參數(shù)。差異的環(huán)境參數(shù)所在的數(shù)據(jù)表不能跨云同步，否則會導(dǎo)致應(yīng)用系統(tǒng)部署失敗。

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

• 雙寫的場景：a）業(yè)務(wù)流量在雙中心同時處理，稱為應(yīng)用層雙活，需要同時向雙中心寫入數(shù)據(jù)表。b）應(yīng)用運(yùn)行期記錄微服務(wù)的調(diào)用日志等。理想情況下，應(yīng)該是有業(yè)務(wù)流量在處理時，應(yīng)用才會向數(shù)據(jù)庫中記錄數(shù)據(jù)。實(shí)際項(xiàng)目中，業(yè)務(wù)也會出現(xiàn)特殊情況，在備中心的應(yīng)用，即使沒有流量請求，也會定期寫入一些日志，比如微服務(wù)調(diào)用日志、定時任務(wù)日志、應(yīng)用啟動時更新全局唯一序列號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í)行，在梳理過程中有幾個常見的問題。

• 設(shè)計(jì)和開發(fā)時期，開發(fā)人員應(yīng)該如何做來減少容災(zāi)時候不同步的過濾表？
• 部署和運(yùn)維時期，運(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í)踐，也比較難限時完成改造。因此部署和運(yùn)維期的時候，梳理過濾表和準(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)用失敗，此時能夠識別出錯誤的環(huán)境參數(shù)。應(yīng)對措施是停止對應(yīng)數(shù)據(jù)表的同步，修正讀寫權(quán)限后繼續(xù)部署。
• 備中心應(yīng)用在測試功能時，重點(diǎn)關(guān)注后臺定時任務(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ù)失敗問題。此時可通過應(yīng)急預(yù)案，緊急停止或增加同步功能或修正數(shù)據(jù)表字段值，重啟應(yīng)用方式的手段來恢復(fù)。在下次演練前修正過濾表清單。本文后面將對此場景用一個案例簡單說明。

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

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

應(yīng)用層角度
接下來我們從應(yīng)用開發(fā)商比較關(guān)注點(diǎn)幾個階段，分析如何有效性地基于云容災(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è)難以接受的。
• 考慮為每朵云和每個中心預(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)注定時任務(wù)。
• 建議將這些功能開關(guān)的操作放在白屏界面，便于在容災(zāi)切換有限而緊迫的時間內(nèi)，允許運(yùn)維人員快速操作，而不是打電話到處問人，關(guān)閉某個定時任務(wù)是在哪個庫、哪個表的哪個字段來控制開關(guān)。
• 記錄過濾表清單，并及時更新。

2.開發(fā)階段：

• 優(yōu)先使用配置中心來保存參數(shù)。實(shí)際項(xiàng)目中，保存配置的方式有多種方式，包括配置中心、配置文件、RDS MySQL、甚至還有在代碼中直接編碼某個地址、賬號密碼。阿里云EDAS產(chǎn)品提供配置中心功能，支持動態(tài)配置、靜態(tài)配置，以及配置變更后動態(tài)推送，而不需要應(yīng)用重啟才能生效。
• 配置中心本身的地址，可以記錄在應(yīng)用的配置文件中，將配置文件和應(yīng)用程序一起打包發(fā)布。因?yàn)榕渲弥行姆?wù)在部署后，很少會發(fā)生變化。
• 如果暫時無法使用配置中心，必須要用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)清楚每個過濾表的被選中的原因，背后的業(yè)務(wù)依據(jù)是什么？重點(diǎn)關(guān)注是否多配了過濾表。
• 登陸每個數(shù)據(jù)庫，檢查容災(zāi)切換平臺ASR-DR是否按照預(yù)期來設(shè)置過濾表。當(dāng)過濾表有上百個的時候，容易出現(xiàn)遺漏或錯誤。
• 創(chuàng)造條件在備中心上提前驗(yàn)證業(yè)務(wù)功能，重點(diǎn)關(guān)注過濾表場景是否符合預(yù)期，關(guān)注定時任務(wù)是否只在一個中心上運(yùn)行。

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

• 配置變更在兩朵云上的過濾表同時執(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上修改這個表是否同步的標(biāo)志。
• 同步表改為過濾表。早期同步的表，由于業(yè)務(wù)做了調(diào)整，后續(xù)無需再同步，需要在容災(zāi)管理平臺ASR-DR并在容災(zāi)管理平臺ASR-DR上修改這個表是否同步的標(biāo)志。

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

五 案例

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

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

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

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

• 確認(rèn)沖突的字段值為交易流水號ID。檢查業(yè)務(wù)數(shù)據(jù)表，確認(rèn)這個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)這個交易記錄號是在主中心使用過了。
• 分析備中心應(yīng)用獲取序列號的記錄。從應(yīng)用日志看到，備中心應(yīng)用在首次啟動時，獲取了一次最新的序列號，后面沒有再從數(shù)據(jù)庫獲取最新的序列號。同時檢查應(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ù)據(jù)庫中獲取1萬個可用的序列號，并更新數(shù)據(jù)庫和應(yīng)用的內(nèi)存值。
• 分析主備中心上的數(shù)據(jù)同步機(jī)制：作為管理全局唯一性序列號的數(shù)據(jù)表xx_table，通過數(shù)據(jù)同步工具DTS能夠保證數(shù)據(jù)實(shí)時在雙中心之間同步，且應(yīng)用在更新數(shù)據(jù)庫序列號時，對數(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ù)據(jù)庫失敗，提示無寫權(quán)限，因此交易功能初始化失敗。在主備架構(gòu)下，默認(rèn)主中心應(yīng)用對RDS MySQL有讀寫權(quán)限，備中心對RDS MySQL有只讀權(quán)限。而備中心啟動時需要些權(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)限時，允許更新序列號失敗，應(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ù)請求失敗（符合預(yù)期）。手動設(shè)置備中心數(shù)據(jù)庫為讀寫，業(yè)務(wù)請求成功，檢查應(yīng)用是否成功重新獲取到有效序列號。重新配置主中心和備中心數(shù)據(jù)同步鏈路。
• 容災(zāi)演練：再次進(jìn)行演練來驗(yàn)證全業(yè)務(wù)場景。

改進(jìn)前

?

改進(jìn)后

?

六 小結(jié)

• 容災(zāi)演練是發(fā)現(xiàn)系統(tǒng)性問題的起點(diǎn)，不是終點(diǎn)，需要定期開展演練來保鮮系統(tǒng)的容災(zāi)能力。
• 云平臺容災(zāi)不等于應(yīng)用容災(zāi)，應(yīng)用級容災(zāi)是系統(tǒng)性工程。
• 通過演練來檢查工程能力，技術(shù)上包括云平臺、應(yīng)用和網(wǎng)絡(luò)；流程上包括故障判斷、容災(zāi)決策、切換操作、應(yīng)急預(yù)案等。

作者：開發(fā)者小助手_LS

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載

總結(jié)

以上是生活随笔為你收集整理的应用容灾中，MySQL数据表是否需要跨云同步？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。