如何實現(xiàn)移動端接入數(shù)據(jù)庫故障自愈

本篇內(nèi)容介紹了“如何實現(xiàn)移動端接入數(shù)據(jù)庫故障自愈”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

對于節(jié)假日，難得的假期，尤其是外出的時候碰上幾個數(shù)據(jù)庫報警，那些報警又屬于不得不處理的時候，真是讓人上火，所以也想了一些辦法來盡可能杜絕和避免這種情況。

一般來說是這樣的幾種策略：

1)提前在節(jié)假日的時候把報警的閾值調(diào)低，然后提前處理一波

2)在假期中期，主動進行巡檢分析，至少在可控的時間里碰到問題提前處理比臨時出現(xiàn)問題緊急解決要好得多。

3)多人互備，通常這種情況比較苦逼，得背著電腦到處跑，還得注意電腦電源，網(wǎng)絡(luò)

當然也有一些機制可以借鑒，大體也是兩類：

1)對于一些通?？煽氐奶幚韱栴}，可以設(shè)定周期性任務(wù)進行提前處理，比如數(shù)據(jù)庫的binlog增長較快，可以設(shè)置周期性任務(wù)來清理，通常定制化，本地化程度較高

2)對于一些可以預(yù)見的問題，可以設(shè)置處理動作腳本，然后周期性掃描，一旦發(fā)現(xiàn)問題就觸發(fā)處理機制，所以這種模式通常是會碰到報警/報警恢復(fù)的周期性交替。

當然這些策略還不是上策，畢竟不夠通用，有的時候問題還具有差異性，需要差異化處理。

舉個例子來說，磁盤報警，如果磁盤報警在80%，那么問題其實緊急度還沒那么高，處理機制優(yōu)先處理磁盤空間能搞定最好，如果達到了90%，磁盤空間的清理改進空間就很有限了，就需要清理數(shù)據(jù)庫日志等，如果繼續(xù)增長問題的緊急度就會逐步升級，就需要接入業(yè)務(wù)邏輯，從一些日志表的數(shù)據(jù)來入手了。

大多數(shù)情況下的問題，通常通過系統(tǒng)空間清理和binlog的清理能夠減緩問題的進一步升級，所以能夠緩沖幾個小時的時間也是很難得的。

和移動端的接入，也是和開發(fā)同事進行了深入溝通后集成起來的，這是一套已經(jīng)穩(wěn)定運行許久的功能模塊，這方面我們還算是接入相對晚了。

移動端對于磁盤報警的處理，我定義的處理流程如下：

在觸發(fā)報警后，在移動端可以對每個處理動作進行處理，后端會有相應(yīng)的API和腳本進行調(diào)用，返回相應(yīng)的數(shù)據(jù)參數(shù)。

整個流程中，對于報警類別的定義和處理流程的編排是相對核心的步驟。

拆分下來，最細粒度的是每一個處理動作的定義。

后續(xù)基本能夠放心的外出，在收到臨時的報警后，心里也會波瀾不驚了。

無論如何，這都是故障自愈的一個好的開始。

“如何實現(xiàn)移動端接入數(shù)據(jù)庫故障自愈”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！