《騰訊高級(jí)工程師祝海強(qiáng)深度剖析騰訊云自動(dòng)運(yùn)維平臺(tái)》要點(diǎn)：
本文介紹了騰訊高級(jí)工程師祝海強(qiáng)深度剖析騰訊云自動(dòng)運(yùn)維平臺(tái)，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

祝海強(qiáng),騰訊高級(jí)工程師.8年數(shù)據(jù)庫經(jīng)歷,曾就職于第九城市、返利網(wǎng)任高級(jí)DBA.目前負(fù)責(zé)騰訊云CDB for MySQL運(yùn)維團(tuán)隊(duì),對(duì)MySQL、MSSQL等數(shù)據(jù)庫運(yùn)維、調(diào)優(yōu)診斷具有豐富的經(jīng)驗(yàn).

---

一、自動(dòng)運(yùn)維平臺(tái)的作用

1.CDB日常維護(hù)工作

CDB即云數(shù)據(jù)庫(Cloud Database),主要具有以下特點(diǎn)：

(1)云存儲(chǔ)服務(wù),是騰訊云平臺(tái)提供的分布式數(shù)據(jù)存儲(chǔ)服務(wù)

(2)完全兼容MySQL協(xié)議

(3)提供了高性能、高可靠、易用、便捷的MySQL集群服務(wù)

(4)整合了備份、擴(kuò)容、遷移等工具,同時(shí)提供CDB管理臺(tái),開發(fā)者可以方便的進(jìn)行登錄、數(shù)據(jù)庫和表的增刪查改等工作

(5)現(xiàn)網(wǎng)CDB的運(yùn)營數(shù)據(jù)接近3PB,接入業(yè)務(wù)包括微信紅包,騰訊彩票,騰訊話費(fèi)充值,餓了么,微信電影票等等

CDB基本架構(gòu)：

用戶在計(jì)算機(jī)房或是阿里云上,自建的MySQL通過?HAproxy或者transfer去打通,就可以導(dǎo)MySQL導(dǎo)數(shù)據(jù)到CDB里邊.下圖為CBD的一個(gè)基本架構(gòu)：

自動(dòng)運(yùn)維平臺(tái)日常維護(hù)CDB的工作：

• 設(shè)備初始化及大量的實(shí)例申請(qǐng)
• 主機(jī)硬件故障、過保設(shè)備下線、機(jī)房裁撤
• 大量業(yè)務(wù)擴(kuò)容支持/低負(fù)載成本優(yōu)化
• 實(shí)例主從切換、備份、高負(fù)載等case處理

2.擴(kuò)容/縮容

由于騰訊云正在飛速發(fā)展,目前大概已有六萬多的實(shí)例,靠人工去進(jìn)行升級(jí)實(shí)例、遷移、切換是無法支持的,所以引入了自動(dòng)化的運(yùn)維平臺(tái).微信紅包就是一個(gè)典型的例子,春節(jié)的量非常大,一擴(kuò)容可能就是上千臺(tái)機(jī)器,而過完年以后就需要縮容.這些工作量都是非常大的.

二、平臺(tái)四大模塊

1.資源管理模塊

(1)設(shè)備初始化持續(xù)部署

• 不同機(jī)型環(huán)境的初始化

不同的機(jī)型做了哪些事情或者進(jìn)行了哪些參數(shù)的調(diào)優(yōu).

• MySQL、TGW、cdb_report、AJS等基礎(chǔ)服務(wù)安裝

包括 MySQL server 在機(jī)器上的部署,還有TGW(異常容災(zāi)切換)、cdb_report(性能采集agent)、AJS(任務(wù)運(yùn)行agent)這些主鍵的安裝,用來維護(hù)后端發(fā)起的遷移任務(wù).這些主鍵將會(huì)在后面講到.

(2)資源監(jiān)控

• 根據(jù)近3個(gè)月的申請(qǐng)量監(jiān)控各規(guī)格實(shí)例的buffer情況
• 實(shí)時(shí)分析異常指標(biāo)進(jìn)行診斷作相應(yīng)處理
• 資源數(shù)據(jù)可視化為月度報(bào)備設(shè)備的核心指標(biāo)

一是在不停的擴(kuò)容和縮容的過程中需要進(jìn)行監(jiān)控.例如運(yùn)維人員不在的情況下線上的實(shí)例少于設(shè)置的閥值,用戶可能在購買實(shí)例的時(shí)候遇到斷貨的情況,資源監(jiān)控的作用就是當(dāng)實(shí)例數(shù)量少于閥值的時(shí)候自動(dòng)從buffer池里拿出來上架.

還有就是統(tǒng)計(jì)每個(gè)月新增機(jī)器的數(shù)量.比如每個(gè)月消化了一百臺(tái)機(jī)器,那么下個(gè)月報(bào)廢設(shè)備的時(shí)候,在不考慮特殊服務(wù)的情況下就是增加一百臺(tái)機(jī)器的量,資源監(jiān)控做出每個(gè)月甚至每天消耗機(jī)器統(tǒng)計(jì)的報(bào)表.

(3)資源循環(huán)

• 同地區(qū)集群之間資源共享
• 已遷移和已下線實(shí)例自動(dòng)回收機(jī)制

例如用戶購買實(shí)例,如果業(yè)務(wù)下線了需要退掉實(shí)例,資源管理模塊會(huì)對(duì)用戶下線的實(shí)例進(jìn)行自動(dòng)回收.

2.運(yùn)維操作模塊

人工運(yùn)維的時(shí)候,MySQL需要做哪些操作?

(1)申請(qǐng)實(shí)例

用戶研發(fā)的時(shí)候需要實(shí)例,一般是找兩臺(tái)機(jī)器,安裝MySQL,搭建一個(gè)主從,提交給研發(fā)用,這個(gè)過程需要手工去申請(qǐng)；

(2)主從切換

最早的版本沒有HA切換,主從掛了以后,告警出來需要手工去切；

(3)遷移實(shí)例

用戶申請(qǐng)實(shí)例發(fā)現(xiàn)內(nèi)存不足,需要進(jìn)行的升級(jí)；

(4)數(shù)據(jù)回檔

假如用戶改錯(cuò)數(shù)據(jù)了,需要通過手工去找回來；

(5)下線實(shí)例

實(shí)例不用了的時(shí)候,需要人工去下線.

實(shí)例操作模塊就是負(fù)責(zé)這些手工操作的模塊.運(yùn)維工具十分龐大,但其實(shí)都是從日常的手工操作發(fā)現(xiàn)需要做哪些事情,哪些事情人工做的比較多,必須減少運(yùn)維的哪些手工操作等等演化過來的.

比如做MySQL的運(yùn)維人員都了解的這個(gè)例子：用戶主機(jī)掛了,然后切到從機(jī)上服務(wù),就會(huì)發(fā)起遷移,通過備份導(dǎo)到新的master上面,再新構(gòu)建一個(gè)主從,通過HA方案切到新的主從識(shí)別上去.

3.平臺(tái)監(jiān)控模塊

平臺(tái)的監(jiān)控模塊的作用在于發(fā)現(xiàn)實(shí)例是否有正常,或者有什么異常：

撥測(cè)Svr的作用就是模擬用戶連接和讀寫CDB實(shí)例,如失敗,則告警,并將失敗錯(cuò)誤碼和錯(cuò)誤內(nèi)容返回.

如果撥測(cè)連不進(jìn)?MySQL server,撥測(cè)就會(huì)跟另一個(gè)模塊DB master打交道?,DB master通過一個(gè)長鏈接一直連到MySQL ,DB master就會(huì)進(jìn)去看連接是不是滿了或者有沒有死鎖,看完以后就會(huì)提交告警,并且下發(fā)到Apd Netman.

Apd Netman 會(huì)做一些監(jiān)控、告警的收斂,如果用過CBD還可以通過采集 MySQL 性能數(shù)據(jù)的工具cdb_report 看到監(jiān)控曲線,所以這個(gè)系統(tǒng)是旁路監(jiān)控系統(tǒng)的一個(gè)重要模塊.

cdb_report相關(guān)監(jiān)控項(xiàng)：

以上幾個(gè)模塊就是整個(gè)?CBD 系統(tǒng)的看門狗,檢測(cè)這個(gè)看門狗是不是能正常工作就需要用到另一個(gè)旁路系統(tǒng)——平臺(tái)自身的監(jiān)控系統(tǒng)來監(jiān)控這些主鍵是否正常運(yùn)行,查看所有模塊的健康狀態(tài).

4.平臺(tái)自愈模塊

監(jiān)控出現(xiàn)問題以后就交給人去處理,但是線上那么多實(shí)例,單靠人工很難維持,所以平臺(tái)加了一個(gè)自愈的模塊,把經(jīng)常出現(xiàn)的異常加入到故障的自愈列表里,出現(xiàn)故障以后先到自愈模塊去走一遭,如果走不通,再通知運(yùn)維去干.

這個(gè)自愈模塊包括一些MySQL經(jīng)常會(huì)出現(xiàn)的問題：

1)復(fù)制異常

由于MySQL主從的架構(gòu),可能出現(xiàn)從機(jī)跟主機(jī)的通信被中斷的情況,大概有以下四種：

• Could not parse relay log event entry? ->refetch_relay_log

問題：第一種就是relay_log在從機(jī)損壞了,如果沒有及時(shí)處理,這時(shí)主機(jī)的relay_log被干掉,bug被修復(fù)以后可能會(huì)丟數(shù)據(jù),做過DBA都知道一般主機(jī)、從機(jī)重啟會(huì)導(dǎo)致relay被損壞 .

解決：可以通過一個(gè)方法開啟relay_log,就是從第二個(gè)起就不要了,重新拿一次主庫的relay_log再回來回放就好了；

• Incorrect key file for?table? ->repair_table

問題：用過MySQL的應(yīng)該也會(huì)經(jīng)常碰到,如果一個(gè)表在操作,如果機(jī)器斷鏈了,或者如果操作被kill掉了,它沒有自動(dòng)回滾的,然后再起來服務(wù)以后它就會(huì)報(bào)這個(gè)表是損壞的狀態(tài).

解決：數(shù)據(jù)異常以后對(duì)這個(gè)表做repair_table；

• Delete_rows event on table ->skip
• Duplicate entry? ->skip

問題：這兩個(gè)比較像.如果主從數(shù)據(jù)已經(jīng)不一致,如果對(duì)數(shù)據(jù)進(jìn)行修改,在主機(jī)上面給一條數(shù)據(jù)的時(shí)候發(fā)現(xiàn)從機(jī)沒有,它就會(huì)報(bào)找不到這個(gè)表.

解決：暫時(shí)跳過,然后對(duì)于主機(jī)上有的數(shù)據(jù)從機(jī)上沒有的就以主庫為主,再引入另外一個(gè)工具?table-sync?自動(dòng)修復(fù)從機(jī)的數(shù)據(jù).

• 記錄配置DB&發(fā)送報(bào)表

無論是發(fā)現(xiàn)的自愈,還是自愈后的補(bǔ)救措施都會(huì)記錄到配置DB里,第二天再通過郵件發(fā)報(bào)表告訴運(yùn)維人員復(fù)制異常自愈模塊做了哪些工作,讓他們知道這些東西要再跑一個(gè)腳本去看這個(gè)模塊是不是在正常工作.

2)備份異常

備份異常和修復(fù)方法：

• Got error 32 on write hadoop ->retry

問題：這個(gè)是典型某個(gè)節(jié)點(diǎn)掛了,或者是當(dāng)時(shí)網(wǎng)絡(luò)有瞬斷,會(huì)報(bào)的一個(gè)32管道的錯(cuò)誤,由于那么大的量,各種網(wǎng)絡(luò)上抖動(dòng)等錯(cuò)誤不能避免.

解決：一旦發(fā)現(xiàn)備份失敗,平臺(tái)立馬就會(huì)去重試備份.另外冷對(duì)系統(tǒng)有異常的時(shí)候,也會(huì)報(bào)錯(cuò),雖然錯(cuò)誤可能不是一樣的,但是具體的操作都是重試.

• Mysql has gone away ->retry

問題：如果MySQL自己出現(xiàn)了異常,比如在備份的時(shí)候,然后這個(gè)備份的selection被犧牲掉了,或者是業(yè)務(wù)進(jìn)程把select給kill掉了,

解決：當(dāng)捕捉到這個(gè)異常也是進(jìn)行重試.

• Incorrect key file for table ->repair table

問題：這個(gè)跟復(fù)制異常的那一點(diǎn)也很像,其實(shí)就是把表損壞了.

解決：在復(fù)制異常的時(shí)候會(huì)去做表的修復(fù).

3)最大連接數(shù)

• Check_lock ->kill select

問題：如果撥測(cè)的時(shí)候發(fā)現(xiàn)連接跑滿了導(dǎo)致MySQL進(jìn)不去.

解決：由于DB master 是一直通過長鏈接在MySQL上面的,所以撥測(cè)檢測(cè)到異常的時(shí)候仍然可以進(jìn)去,就可以去check-load,是什么東西導(dǎo)致了所有的連接數(shù)跑滿,然后select,假如發(fā)現(xiàn)它是表鎖了,就針對(duì)這種select犧牲掉它,讓整個(gè)MySQL server恢復(fù)正常.

• Check_sleep ->reset timeout

問題：另一種是沒有鎖的情況,只是業(yè)務(wù)單純的sleep?導(dǎo)致連接滿了,這是因?yàn)閷?shí)例規(guī)格不同,對(duì)最大連接數(shù)的設(shè)置也是不一樣的.

解決：為了避免運(yùn)維凌晨起來,就可以把time out設(shè)久一點(diǎn),比如sleep如果默認(rèn)是八個(gè)小時(shí),比如第一次設(shè)到一個(gè)小時(shí),如果還緩存不了,就設(shè)到60秒,如果還緩存不了,運(yùn)維人員再去處理.

• Reset max_conn

問題：如果通過time out也解決不了問題.

解決：可以在這個(gè)服務(wù)器負(fù)載允許的情況下,就是內(nèi)存容納還夠的情況下擴(kuò)大它的最大連接數(shù).

4)鎖等待

問題：鎖等待就是發(fā)現(xiàn)死鎖以后怎么去做：

• Check_active_conn

解決：一種就是通過活動(dòng)連接這個(gè)最直觀的方法,如果鎖很多的時(shí)候活動(dòng)連接就會(huì)很多；

• Check_lock? ->kill select

第二種就是通過運(yùn)用DB自身的系統(tǒng)庫去做一些判斷,如果檢查到連接數(shù)是一樣的情況下,就像剛才一樣表鎖了就指定犧牲掉；

5)極端高負(fù)載

• Check_load
• Auto_repair

問題：如果機(jī)器負(fù)載很高.

解決：平臺(tái)會(huì)做一些高負(fù)載的修復(fù)方法,比如看到某一個(gè)實(shí)例的負(fù)載很高,平臺(tái)就會(huì)判斷MySQL是不是可以通過加索引去解決,如果可以,線上就會(huì)自動(dòng)去加一個(gè)索引先修復(fù),運(yùn)維人員可以在第二天上班時(shí)間再去跟進(jìn).

三、平臺(tái)的總體架構(gòu)

平臺(tái)的總體架構(gòu)共分為四塊：

1.Web Server

Web Server就是一個(gè)可視化的界面,后端提供一些API的服務(wù),例如從主機(jī)到從機(jī)發(fā)起的遷移就是一個(gè)常任務(wù),可能需要兩三天的時(shí)間.

2.后臺(tái)作業(yè)系統(tǒng)

常任務(wù)里包括數(shù)據(jù)對(duì)比這些東西,有一個(gè)作業(yè)系統(tǒng)進(jìn)行管理,負(fù)責(zé)協(xié)調(diào)前端或者后端通過API發(fā)起的任務(wù)到公眾模塊的銜接；

3.功能模塊

包括資源分配、備份中心、數(shù)據(jù)遷移、HA模塊以及提供給客戶的接口,客戶通過API就可以拿到最大連接；

4.基礎(chǔ)服務(wù)組件

• 任務(wù)運(yùn)行agent：AJS
• 性能采集agent：cdb_report
• 異常容災(zāi)切換：TGW

基礎(chǔ)服務(wù)組件包括騰訊內(nèi)部的一個(gè)AJS系統(tǒng)；后端cdb-report是自研的一個(gè)采集器；還有異常切換需要用到騰訊的Tencent GateWay(TGW).

平臺(tái)總體架構(gòu)圖：

 

轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4341.html