萬級實(shí)例規(guī)模下的數(shù)據(jù)庫故障自愈探索實(shí)踐

作者：林鋒英 2022-12-15 07:53:34

隨著運(yùn)維規(guī)模越大，線上故障也就越多，DBA 對于每個故障的處理時效將會下降，如果沒有強(qiáng)有力的工具能提高故障的排查和修復(fù)效率，那么線上的穩(wěn)定性就得不到保障。因此我們的想法是，我們固然要不斷提供更加豐富的工具，但無論工具再豐富，都需要人去主動使用，因此更重要的是改變以人為主、工具為輔的運(yùn)維模式，引入自動化分析和自愈的手段來提升運(yùn)維效率。

1.背景

近幾年 vivo 數(shù)據(jù)庫運(yùn)維規(guī)模快速增長，從數(shù)量上看增長了幾倍，達(dá)到了萬級別的規(guī)模，與此同時 DBA 每日需要處理200多條告警。

2.實(shí)現(xiàn)思路

2.1 短期和長期目標(biāo)

目標(biāo)確定后，接下來需要確定目標(biāo)的實(shí)現(xiàn)思路。我們調(diào)研了業(yè)界的一些解決方案后，發(fā)現(xiàn)能力的發(fā)展可以總結(jié)為以下三個階段：

平臺化：能夠提供一些數(shù)據(jù)和統(tǒng)計信息，運(yùn)維人員再基于這些信息來進(jìn)行運(yùn)維；
智能化：已經(jīng)能夠提供分析和建議，但是否采納需要運(yùn)維人員自行判斷；
自動化：已經(jīng)有部分場景可以實(shí)現(xiàn)自動恢復(fù)，無需人工參與了。

通常平臺的發(fā)展過程如上所述，但是也需要結(jié)合我們自身的情況來決定，因?yàn)槲覀兺度氲娜肆^少，不是成團(tuán)隊(duì)地投入這個工作，因此不太可能遵循這么一個發(fā)展策略。因此基于人力投入的情況，我們定下的目標(biāo)是，短期內(nèi)我們要做投入產(chǎn)出比最高的工作，以求達(dá)到立竿見影的效果，但長期來看，圖中成體系的基礎(chǔ)能力還是需要建設(shè)起來。

2.2 尋找切入點(diǎn)

為了短期達(dá)到立竿見影的效果，就需要尋找一個切入點(diǎn)。如果我們觀察一個故障的生命周期的話，可以看到故障的生命周期分為故障前、故障中和故障后：

“故障前”包括故障預(yù)防；
“故障中”包括故障發(fā)現(xiàn)、故障定位和故障恢復(fù)；
“故障后”包括故障復(fù)盤。

那么從整個故障的生命周期來看的話，按照我們的經(jīng)驗(yàn)，DBA 大部分時間都是消耗在故障定位和故障恢復(fù)上的，而因?yàn)槊款惞收暇哂邢嗨频亩ㄎ宦窂剑员容^容易去定義定位規(guī)則、沉淀專家經(jīng)驗(yàn)。因此我們的想法是將重點(diǎn)放在故障定位和故障恢復(fù)這兩個階段上，去提高 DBA 的運(yùn)維效率，優(yōu)先找一些投入產(chǎn)出比高的場景去實(shí)現(xiàn)故障自愈。

2.3 結(jié)合實(shí)際情況后的發(fā)展思路

結(jié)合前面提到的短期目標(biāo)和長期目標(biāo)，我們確定下來這么一個發(fā)展思路。

首先我們會重點(diǎn)去實(shí)現(xiàn)各類故障場景的自動分析和自愈，這些自動分析和自愈行為是由故障消息驅(qū)動的，這也是一個比較直觀的方式，因?yàn)?DBA 通常也是收到故障消息后，才去進(jìn)行故障定位等操作。然后當(dāng)過程中需要某類基礎(chǔ)能力時，就去重點(diǎn)發(fā)展該能力。

這樣我們的短期目標(biāo)和長期目標(biāo)就都能兼顧到。

2.4 如何在實(shí)現(xiàn)過程中保證數(shù)據(jù)庫可用性

在實(shí)現(xiàn)方案前，需要先思考一個問題，即我們?nèi)绾卧趯?shí)現(xiàn)過程中保證數(shù)據(jù)庫的可用性？

之所以把數(shù)據(jù)庫可用性單獨(dú)提出來，是因?yàn)楣收献杂亲詣佑|發(fā)、自動執(zhí)行的，而且過程中通常需要去觸達(dá)數(shù)據(jù)庫，比如查詢數(shù)據(jù)庫的狀態(tài)或執(zhí)行操作，那么這種自動的操作本身會帶來比較大風(fēng)險，因此更加需要考慮實(shí)現(xiàn)過程中，如何避免對數(shù)據(jù)庫造成的可用性影響。那么如何避免可用性影響呢？我們的答案是將每個故障自愈方案上線的流程標(biāo)準(zhǔn)化。

3.具體實(shí)現(xiàn)

3.1 故障自愈方案上線流程

下圖是我們以可用性為第一考量的前提下，確定下來的故障自愈方案上線流程。

①確定方案：當(dāng)有一個新的故障自愈場景需要實(shí)現(xiàn)時，首先需要把自愈方案確定下來，即確定在這個故障場景中，需要“做什么、怎么去做”。這里有兩種確定方案的方式，可以和 DBA 進(jìn)行咨詢交流確定方案，也可以通過分析線上案例來確定方案

②開發(fā)測試：方案確定后進(jìn)行程序的開發(fā)測試，此處不必贅述

③線上灰度：開發(fā)測試完成后，需進(jìn)行線上灰度，這里我們支持針對具體對象進(jìn)行灰度，比如某個集群經(jīng)常發(fā)生該類故障，那么可以指定灰度該集群。如果沒有具體對象，也可以設(shè)置百分比隨機(jī)灰度。當(dāng)然如果某些故障場景發(fā)生的頻率很低，我們一開始也會進(jìn)行線上演練，通過在線上模擬故障的方式來進(jìn)行驗(yàn)證

④全網(wǎng)生效：灰度完成后，開放全網(wǎng)生效

⑤演進(jìn)方案：每個故障自愈方案不是上線后就是最終形態(tài)，還需要我們結(jié)合用戶反饋以及后續(xù)案例來不斷進(jìn)行迭代優(yōu)化

上述流程的五個步驟中，“確定方案”和“演進(jìn)方案”是重點(diǎn)，因此下文展開介紹。

3.1.1 確定方案

在實(shí)踐中，我們通過和 DBA 咨詢交流以及分析線上案例的方式來確定故障自愈的方案。

咨詢交流

這里介紹下發(fā)生磁盤告警時自動清理 MySQL Binlog 的方案，通過和 DBA 咨詢交流的方式，我們確定了該方案。具體方案流程如下圖所示，其實(shí)整個方案就重點(diǎn)關(guān)注了兩個問題：

第一個問題，如何確定哪些 Binlog 是不可以清理的？答案是未備份的 Binlog 不能清理，因?yàn)闀绊懺隽總浞荩粋鋷煳赐降?Binlog 也不能清理，因?yàn)闀绊憦?fù)制同步。

第二個問題，如何保證刪除過程中的系統(tǒng)可用性？這里我們采用分批刪除、每次刪除睡眠一秒的方式來平滑刪除帶來的 IO 壓力。

案例分析

有時不是所有方案都能夠通過咨詢交流的方式確定下來，對于根因分析的場景，因?yàn)槊總€運(yùn)維人員的運(yùn)維經(jīng)歷有所差別，如果要把所有可能的情況枚舉出來，那么會導(dǎo)致方案十分冗長，因此一種更好的方法是通過分析線上真實(shí)案例來確定方案，這樣產(chǎn)出的方案是最貼合線上情況的，后續(xù)也可以不斷結(jié)合案例做迭代優(yōu)化。

這里介紹下我們?nèi)绾未_定 SQL 類告警根因 SQL 分析方案。為了確定這個方案，我們分析了50個線上案例：首先找出哪些案例是能明顯看出有根因 SQL 的，再對有根因 SQL 的類別進(jìn)行細(xì)化，最后得到根因 SQL 的判斷步驟。

3.1.2 演進(jìn)方案

針對某個故障場景的方案通常不是一步到位、直接擁有自動恢復(fù)故障的能力的，而是在實(shí)踐中不斷演進(jìn)。我們把方案演進(jìn)的過程分為下圖三個階段：

那么為什么要分階段去演進(jìn)方案呢？

從效率的角度看，能夠先快速上線比較簡單的方案，可以快速地提高運(yùn)維效率；

從可用性的角度看，前一階段是后一階段的基礎(chǔ)，只有前一階段驗(yàn)證成熟了，再去不斷演進(jìn)是比較安全的做法。

以 SQL 故障場景為例來演示方案的演進(jìn)過程。我們的 SQL 故障場景方案一開始只是提供數(shù)據(jù)和統(tǒng)計，然后進(jìn)一步地通過案例分析的方式，使其可以根據(jù)規(guī)則嘗試找出導(dǎo)致告警的根因 SQL，目前正在實(shí)現(xiàn)對根因 SQL 的自動優(yōu)化建議，最終目標(biāo)是可以具備對問題 SQL 自動優(yōu)化、自動限流的能力。

3.2 故障自愈流程

基于上述的思路，我們實(shí)現(xiàn)了一個故障消息驅(qū)動、基于規(guī)則的故障自愈流程。

首先我們監(jiān)聽了故障消息，當(dāng)自愈系統(tǒng)接收到故障消息時，會根據(jù)這個消息類型去規(guī)則庫中查找對應(yīng)的自愈流程，再通過流程編排引擎運(yùn)行起來。流程中會去調(diào)用相關(guān)基礎(chǔ)能力，最后生成一個處理結(jié)果通知，發(fā)送到我們的工作溝通軟件。同時也會將這次流程的運(yùn)行信息保存到分析中心，用戶后續(xù)可以在分析中心看到詳細(xì)的現(xiàn)場快照、分析結(jié)果，還能對這次分析進(jìn)行評價標(biāo)注。

下面對流程中的重點(diǎn)組件進(jìn)行介紹。

3.2.1 故障消息

首先是故障消息，在一開始設(shè)計時，我們期望是可以支持接入各種故障消息，比如告警事件、巡檢事件等，但是在實(shí)踐中，我們還是優(yōu)先針對 TOP 告警場景進(jìn)行開發(fā)，因?yàn)楣收舷⒅校^大部分都是告警。而且據(jù)我們統(tǒng)計，TOP 5 的告警差不多占了所有告警的一半，優(yōu)先針對 TOP 告警短期內(nèi)能取得不錯的效果。

3.2.2 規(guī)則庫

規(guī)則庫保存了故障消息類型和自愈流程的綁定關(guān)系，自愈系統(tǒng)收到故障消息后，會根據(jù)這個消息類型去規(guī)則庫中查找對應(yīng)的自愈流程。這里我們實(shí)現(xiàn)了一個簡單的流程編排功能，我們的想法是，先實(shí)現(xiàn)一些原子操作，再去將這些操作組合成一個流程，這樣可以讓操作具有的復(fù)用性，也更容易實(shí)現(xiàn)新的流程。

比如針對 CPU 告警，我們將 TOP 分析和 SQL 根因分析獨(dú)立成兩個原子操作，這樣這兩個操作也能復(fù)用在其他流程中。

3.2.3 分析中心

在分析中心，用戶可以看到監(jiān)控告警詳情、現(xiàn)場快照、分析的結(jié)果，還可以通過這里向我們反饋這個告警的原因、如何排查等信息，幫忙我們?nèi)ミM(jìn)行迭代優(yōu)化。這樣自愈流程就不是一個黑盒了，也方便運(yùn)維人員之間進(jìn)行協(xié)作。

3.3 數(shù)據(jù)采集和計算

3.3.1 數(shù)據(jù)采集

故障自愈需要大量的數(shù)據(jù)支持，我們將數(shù)據(jù)分為三種類型。

監(jiān)控數(shù)據(jù)：我們這邊的數(shù)據(jù)庫種類比較多，每種數(shù)據(jù)庫都有自己監(jiān)控采集方式；

日志數(shù)據(jù)：采集流程中 Agent 先會向 Manager 查詢自己需要采集哪些日志，然后以類似 tail 的方式一行一行地采集，再上報給 Manager，最后由 Manager 根據(jù)配置的正則表達(dá)式解析成結(jié)構(gòu)化數(shù)據(jù)，寫入 Kafka。這些日志包括慢日志、運(yùn)行日志、全量日志等；

事件數(shù)據(jù)：我們開發(fā)了一個事件系統(tǒng)的 SDK，由各個服務(wù)使用這個 SDK，將自己服務(wù)的事件上報到事件系統(tǒng)。

3.3.2 數(shù)據(jù)計算

數(shù)據(jù)采集后，一些數(shù)據(jù)需要做計算處理。我們現(xiàn)在對數(shù)據(jù)做實(shí)時計算的場景比較少，下圖是近期的全量 SQL 需求。

首先由 Agent 采集 SQL LOG 文件，進(jìn)行批量上報，為了降低 Kafka 的帶寬壓力，上報的時候需要進(jìn)行壓縮。上報時指定實(shí)例地址作為 Kafka 分區(qū) Key，以保證同一個實(shí)例的數(shù)據(jù)能寫到同一個 Kafka 分區(qū)，因此也就能保證在實(shí)時計算端，同一個實(shí)例的數(shù)據(jù)會落在同一個處理線程上，這樣就能在接收到數(shù)據(jù)后，做一個預(yù)聚合，降低發(fā)往下游的網(wǎng)絡(luò)流量。然后通過逐層聚合的方式，先聚合出每分鐘每個 SQL_ID 的平均執(zhí)行次數(shù)、平均響應(yīng)時間等指標(biāo)，再根據(jù)SQL_ID 的聚合數(shù)據(jù)，聚合出每分鐘每個 Table 的平均訪問次數(shù)指標(biāo)。最后這份數(shù)據(jù)將用以支撐 SQL 趨勢、表流量統(tǒng)計、SQL 過載保護(hù)等功能。

4.成果和案例

4.1 成果

10+種故障場景分析和自愈能力：

使用6人月覆蓋線上70%以上告警：

4.2 案例

這里介紹一個案例：長時間執(zhí)行的 SQL 數(shù)量達(dá)到閾值后，產(chǎn)生了告警，根據(jù) SQL 根因分析得出，這是因?yàn)橛幸粭l長時間運(yùn)行的 SQL 阻塞了其他 SQL，并把分析結(jié)果推送到故障處理群。從分析詳情可以看出，這是一個 MDL 鎖等待的經(jīng)典場景，因?yàn)槟硹l SQL 長時間運(yùn)行，備份進(jìn)程執(zhí)行 FLUSH 時請求 MDL 被阻塞，繼而引發(fā)后續(xù) SQL 請求 MDL 阻塞。