高可用是數(shù)據(jù)庫系統(tǒng)的基本需求,也是數(shù)據(jù)庫技術(shù)實現(xiàn)的難點之一。但對于有些行業(yè)來說,“零停機”,是剛需!
比如半導體行業(yè),停機哪怕一分鐘都可能造成高達數(shù)萬美元的直接經(jīng)濟損失;比如航空業(yè),航班調(diào)度系統(tǒng)一旦出現(xiàn)故障,成千上萬的旅客行程將受到影響,航空公司可能要面臨天文數(shù)字的賠償;再比如醫(yī)療行業(yè),停機可能直接關(guān)系著患者的生命安全!
那么,支撐這些尖端產(chǎn)業(yè)的數(shù)據(jù)庫是如何實現(xiàn)近乎神話般的“零停機”的呢?
要理解這一奇跡背后的奧秘,我們必須首先識別并解決影響數(shù)據(jù)庫可靠性的幾個常見問題:
問題1:數(shù)據(jù)庫高可用架構(gòu)以及災(zāi)備架構(gòu)不完善
問題2:數(shù)據(jù)庫運行性能及穩(wěn)定性問題
問題3:故障應(yīng)急處理缺乏規(guī)范流程和方案
問題4:缺少高效運維體系
問題5:缺少主動式隱患梳理及預(yù)防
......
針對這些普遍問題,中亦科技經(jīng)過多年技術(shù)與經(jīng)驗積累,總結(jié)出以下關(guān)鍵點!
一
高可用架構(gòu)與災(zāi)備
堅固基石,方能抵御風暴
許多企業(yè)的數(shù)據(jù)庫高可用架構(gòu)及災(zāi)備體系并不完善。為了解決這一問題,我們可以根據(jù)業(yè)務(wù)系統(tǒng)的重要性,將其分為幾個不同的等級,并為每個等級量身定制相應(yīng)的高可用架構(gòu)及災(zāi)備方案。
其中核心系統(tǒng)屬于A類系統(tǒng)。A/B/C/D類業(yè)務(wù)系統(tǒng)生產(chǎn)端數(shù)據(jù)庫的架構(gòu)都是RAC集群,區(qū)別為是否配置了ADG,是采用小型機還是X86,是在一套集群上部署一套還是兩套數(shù)據(jù)庫。分類之后再進行核心業(yè)務(wù)系統(tǒng)和核心系統(tǒng)除外的災(zāi)備架構(gòu)和實現(xiàn)方式。
核心業(yè)務(wù)系統(tǒng)高可用架構(gòu)圖
二
數(shù)據(jù)庫補丁管理
精準施策,防范未然
適時地進行補丁分析與升級至關(guān)重要。當遇到新版本操作系統(tǒng)或數(shù)據(jù)庫安裝、季度PSU補丁發(fā)布等情況時,就需要進行詳盡的補丁分析,以避免潛在問題。這一過程不僅需要精確的分析策略,還需要完善的補丁升級計劃,確保數(shù)據(jù)庫始終保持在最佳狀態(tài)。
那么,什么時候需要做補丁分析?
以O(shè)racle數(shù)據(jù)庫為例,當出現(xiàn)下列情況時,需要考慮做補丁分析:
在目標版本的操作系統(tǒng)上安裝數(shù)據(jù)庫,為了避免目標版本的OS出現(xiàn)BUG需要分析OS需要安裝哪些補丁。
安裝目標版本的數(shù)據(jù)庫,為了避免新安裝數(shù)據(jù)庫出現(xiàn)嚴重BUG,需要數(shù)據(jù)庫應(yīng)該安裝哪個patchset、哪個PSU補丁及小補丁。
隨著ORACLE季度PSU補丁的發(fā)布,需要關(guān)注新補丁的分布并對嚴重性分類,需要做補丁分析,這樣,已有數(shù)據(jù)庫可以根據(jù)升級策略提前升級補丁以預(yù)防潛在問題。
當已有數(shù)據(jù)庫出現(xiàn)嚴重BUG,考慮安裝補丁時,具體需要安裝哪個PSU補丁。
三
數(shù)據(jù)庫最佳實踐
細節(jié)決定成敗
基于多年服務(wù)經(jīng)驗,我們總結(jié)了一系列最佳實踐,覆蓋操作系統(tǒng)配置、ASM參數(shù)調(diào)整、數(shù)據(jù)庫參數(shù)優(yōu)化等多個方面。通過這些精心設(shè)計的策略,我們能夠有效消除系統(tǒng)運行中的隱患,確保數(shù)據(jù)庫的穩(wěn)健運行。
四
數(shù)據(jù)庫高可用測試
實戰(zhàn)檢驗,確保萬無一失
在數(shù)據(jù)庫系統(tǒng)上線前,進行全面的高可用測試至關(guān)重要。這包括但不限于服務(wù)器單節(jié)點故障、網(wǎng)絡(luò)故障、心跳網(wǎng)絡(luò)故障等場景。通過預(yù)先設(shè)定的測試案例,我們可以驗證系統(tǒng)在面對各種極端條件下的表現(xiàn),確保其能夠在實際應(yīng)用中保持高度的可靠性和穩(wěn)定性。
對RAC集群高可用架構(gòu)和容災(zāi)能力進行測試,主要包含以下幾個場景:
服務(wù)器單節(jié)點故障:服務(wù)器發(fā)生故障重啟是運行期間常見的問題之一,硬件故障,網(wǎng)絡(luò)故障,參數(shù)配置錯誤等都可能導致服務(wù)器不穩(wěn)定或者宕機;一旦服務(wù)器硬件出現(xiàn)故障,數(shù)據(jù)庫隨之也會受到影響,可能會導致數(shù)據(jù)庫重啟或者關(guān)閉。針對這些情況,設(shè)計兩個測試用例分別模擬單節(jié)點手動重啟服務(wù)器和異常宕機時的情景。
服務(wù)網(wǎng)絡(luò)故障:本次預(yù)設(shè)的生產(chǎn)環(huán)境是雙公網(wǎng)網(wǎng)卡和雙私網(wǎng)網(wǎng)卡的rac環(huán)境,其中每組網(wǎng)卡都分為主網(wǎng)卡和備網(wǎng)卡,當公網(wǎng)主網(wǎng)卡出現(xiàn)故障后系統(tǒng)會自動切換到備網(wǎng)卡繼續(xù)運行,理論上這個切換的過程會非常短、不會對業(yè)務(wù)產(chǎn)生影響;同時,因為數(shù)據(jù)庫正常運行時不會用到備網(wǎng)卡,如果是備網(wǎng)卡發(fā)生故障業(yè)務(wù)也不會受到影響。當公網(wǎng)雙網(wǎng)卡同時發(fā)生故障時,服務(wù)器將無法對外開放。
心跳網(wǎng)絡(luò)故障:本次預(yù)設(shè)的生產(chǎn)環(huán)境是雙公網(wǎng)網(wǎng)卡和雙私網(wǎng)網(wǎng)卡的rac環(huán)境,其中每組網(wǎng)卡都分為主網(wǎng)卡和備網(wǎng)卡,當公網(wǎng)主網(wǎng)卡出現(xiàn)故障后系統(tǒng)會自動切換到備網(wǎng)卡繼續(xù)運行,理論上這個切換的過程會非常短、不會對業(yè)務(wù)產(chǎn)生影響;同時,因為數(shù)據(jù)庫正常運行時不會用到備網(wǎng)卡,如果是備網(wǎng)卡發(fā)生故障業(yè)務(wù)也不會受到影響。當私網(wǎng)雙網(wǎng)卡同時發(fā)生故障時,如果較短時間就恢復,集群層面不會出現(xiàn)異常,若超過了misscount時間集群會出現(xiàn)腦裂現(xiàn)象。
服務(wù)器單節(jié)點HANG故障:服務(wù)器運行期間由于硬件或軟件異常原因都有可能導致節(jié)點HANG死。操作系統(tǒng)因CPU、內(nèi)存耗盡或BUG,OS掛起,無法響應(yīng)數(shù)據(jù)庫。針對這些情況,分別設(shè)計0S無法響應(yīng)、cluster軟件關(guān)鍵進程無響應(yīng)、cluster軟件關(guān)鍵進程異常終止、database軟件關(guān)鍵進程無響應(yīng)、database軟件關(guān)鍵進程異常終止、業(yè)務(wù)作業(yè)進程無響應(yīng)等6個大的場景進行測試。
操作人員操作失誤:實際環(huán)境中,有可能存在操作人員誤操作導致數(shù)據(jù)丟失,本次場景分閃回查詢表、延遲閃回adg三個測試用例來分別模擬恢復數(shù)據(jù)。
除此之外還將對san網(wǎng)絡(luò)故障、軟件升級、HBA卡升級等場景進行測試。
五
運維體系建設(shè)
預(yù)防為主,應(yīng)對為輔
構(gòu)建全面的運維體系是保障數(shù)據(jù)庫長期穩(wěn)定運行的基礎(chǔ)。這包括制定詳細的預(yù)防策略、建立完善的監(jiān)控機制、提供詳盡的手冊指南以及系統(tǒng)的培訓支持。通過主動預(yù)防而非被動應(yīng)對,我們能夠顯著降低系統(tǒng)故障率,提高整體服務(wù)質(zhì)量。
運維體系建設(shè)關(guān)系到數(shù)據(jù)庫系統(tǒng)的持續(xù)穩(wěn)定運行,主要內(nèi)容如下:
制定預(yù)防未來可能導致性能不穩(wěn)定的統(tǒng)計信息策略并實施,數(shù)據(jù)存放策略標準;
提供數(shù)據(jù)庫監(jiān)控指標體系和具體實現(xiàn)方式;
制定數(shù)據(jù)庫備份恢復策略;
提供數(shù)據(jù)庫變更手冊、應(yīng)急手冊和維護手冊;
提供系統(tǒng)性的培訓和指導,為客戶后續(xù)的深度自主運維奠定良好的人才基礎(chǔ)。
... ...
為了提升業(yè)務(wù)連續(xù)性和用戶體驗,提升系統(tǒng)可用性、穩(wěn)定性、安全性,全面提升運維質(zhì)量,我們還會制定了數(shù)據(jù)庫運維體系說明手冊,用以指導數(shù)據(jù)庫的日常運維工作。
Oracle運維體系的模型
六
主動式優(yōu)化與問題梳理
防微杜漸,未雨綢繆
數(shù)據(jù)庫運維和消防一樣,永遠都是“預(yù)防重于救火”,被動式的故障處理只能解決突發(fā)的問題,只有主動梳理及預(yù)防才能防患于未然,真正做到事半功倍!
中亦科技會從主動式分析和預(yù)防及基于開發(fā)運維最佳實踐進行問題梳預(yù)防進行說明。主動對數(shù)據(jù)庫運行情況進行性能監(jiān)控,抓取性能表現(xiàn)不佳或擴展性不佳的SQL/PLSQL并進行主動分析,提交優(yōu)化建議。通過梳理并預(yù)防潛在問題,我們能夠提前發(fā)現(xiàn)并解決隱患,減少未來可能出現(xiàn)的問題數(shù)量。
在這個信息爆炸的時代,數(shù)據(jù)庫的可靠性很關(guān)鍵。中亦科技一直在不斷的總結(jié)項目經(jīng)驗,培養(yǎng)專業(yè)技術(shù)團隊,完善服務(wù)體系,希望通過不斷升級的數(shù)據(jù)庫可靠性方案,提高數(shù)據(jù)庫的可用性和穩(wěn)定性!
如果您有數(shù)據(jù)庫可靠性提升的需求,歡迎留言聯(lián)系我們,我們的技術(shù)專家團隊將竭誠為您服務(wù)。