《騰訊高級工程師祝海強深度剖析騰訊云自動運維平臺》要點：
本文介紹了騰訊高級工程師祝海強深度剖析騰訊云自動運維平臺，希望對您有用。如果有疑問，可以聯系我們。

祝海強,騰訊高級工程師.8年數據庫經歷,曾就職于第九城市、返利網任高級DBA.目前負責騰訊云CDB for MySQL運維團隊,對MySQL、MSSQL等數據庫運維、調優診斷具有豐富的經驗.

---

一、自動運維平臺的作用

1.CDB日常維護工作

CDB即云數據庫(Cloud Database),主要具有以下特點：

(1)云存儲服務,是騰訊云平臺提供的分布式數據存儲服務

(2)完全兼容MySQL協議

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

(4)整合了備份、擴容、遷移等工具,同時提供CDB管理臺,開發者可以方便的進行登錄、數據庫和表的增刪查改等工作

(5)現網CDB的運營數據接近3PB,接入業務包括微信紅包,騰訊彩票,騰訊話費充值,餓了么,微信電影票等等

CDB基本架構：

用戶在計算機房或是阿里云上,自建的MySQL通過?HAproxy或者transfer去打通,就可以導MySQL導數據到CDB里邊.下圖為CBD的一個基本架構：

自動運維平臺日常維護CDB的工作：

• 設備初始化及大量的實例申請
• 主機硬件故障、過保設備下線、機房裁撤
• 大量業務擴容支持/低負載成本優化
• 實例主從切換、備份、高負載等case處理

2.擴容/縮容

由于騰訊云正在飛速發展,目前大概已有六萬多的實例,靠人工去進行升級實例、遷移、切換是無法支持的,所以引入了自動化的運維平臺.微信紅包就是一個典型的例子,春節的量非常大,一擴容可能就是上千臺機器,而過完年以后就需要縮容.這些工作量都是非常大的.

二、平臺四大模塊

1.資源管理模塊

(1)設備初始化持續部署

• 不同機型環境的初始化

不同的機型做了哪些事情或者進行了哪些參數的調優.

• MySQL、TGW、cdb_report、AJS等基礎服務安裝

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

(2)資源監控

• 根據近3個月的申請量監控各規格實例的buffer情況
• 實時分析異常指標進行診斷作相應處理
• 資源數據可視化為月度報備設備的核心指標

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

還有就是統計每個月新增機器的數量.比如每個月消化了一百臺機器,那么下個月報廢設備的時候,在不考慮特殊服務的情況下就是增加一百臺機器的量,資源監控做出每個月甚至每天消耗機器統計的報表.

(3)資源循環

• 同地區集群之間資源共享
• 已遷移和已下線實例自動回收機制

例如用戶購買實例,如果業務下線了需要退掉實例,資源管理模塊會對用戶下線的實例進行自動回收.

2.運維操作模塊

人工運維的時候,MySQL需要做哪些操作?

(1)申請實例

用戶研發的時候需要實例,一般是找兩臺機器,安裝MySQL,搭建一個主從,提交給研發用,這個過程需要手工去申請；

(2)主從切換

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

(3)遷移實例

用戶申請實例發現內存不足,需要進行的升級；

(4)數據回檔

假如用戶改錯數據了,需要通過手工去找回來；

(5)下線實例

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

實例操作模塊就是負責這些手工操作的模塊.運維工具十分龐大,但其實都是從日常的手工操作發現需要做哪些事情,哪些事情人工做的比較多,必須減少運維的哪些手工操作等等演化過來的.

比如做MySQL的運維人員都了解的這個例子：用戶主機掛了,然后切到從機上服務,就會發起遷移,通過備份導到新的master上面,再新構建一個主從,通過HA方案切到新的主從識別上去.

3.平臺監控模塊

平臺的監控模塊的作用在于發現實例是否有正常,或者有什么異常：

撥測Svr的作用就是模擬用戶連接和讀寫CDB實例,如失敗,則告警,并將失敗錯誤碼和錯誤內容返回.

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

Apd Netman 會做一些監控、告警的收斂,如果用過CBD還可以通過采集 MySQL 性能數據的工具cdb_report 看到監控曲線,所以這個系統是旁路監控系統的一個重要模塊.

cdb_report相關監控項：

以上幾個模塊就是整個?CBD 系統的看門狗,檢測這個看門狗是不是能正常工作就需要用到另一個旁路系統——平臺自身的監控系統來監控這些主鍵是否正常運行,查看所有模塊的健康狀態.

4.平臺自愈模塊

監控出現問題以后就交給人去處理,但是線上那么多實例,單靠人工很難維持,所以平臺加了一個自愈的模塊,把經常出現的異常加入到故障的自愈列表里,出現故障以后先到自愈模塊去走一遭,如果走不通,再通知運維去干.

這個自愈模塊包括一些MySQL經常會出現的問題：

1)復制異常

由于MySQL主從的架構,可能出現從機跟主機的通信被中斷的情況,大概有以下四種：

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

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

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

• Incorrect key file for?table? ->repair_table

問題：用過MySQL的應該也會經常碰到,如果一個表在操作,如果機器斷鏈了,或者如果操作被kill掉了,它沒有自動回滾的,然后再起來服務以后它就會報這個表是損壞的狀態.

解決：數據異常以后對這個表做repair_table；

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

問題：這兩個比較像.如果主從數據已經不一致,如果對數據進行修改,在主機上面給一條數據的時候發現從機沒有,它就會報找不到這個表.

解決：暫時跳過,然后對于主機上有的數據從機上沒有的就以主庫為主,再引入另外一個工具?table-sync?自動修復從機的數據.

• 記錄配置DB&發送報表

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

2)備份異常

備份異常和修復方法：

• Got error 32 on write hadoop ->retry

問題：這個是典型某個節點掛了,或者是當時網絡有瞬斷,會報的一個32管道的錯誤,由于那么大的量,各種網絡上抖動等錯誤不能避免.

解決：一旦發現備份失敗,平臺立馬就會去重試備份.另外冷對系統有異常的時候,也會報錯,雖然錯誤可能不是一樣的,但是具體的操作都是重試.

• Mysql has gone away ->retry

問題：如果MySQL自己出現了異常,比如在備份的時候,然后這個備份的selection被犧牲掉了,或者是業務進程把select給kill掉了,

解決：當捕捉到這個異常也是進行重試.

• Incorrect key file for table ->repair table

問題：這個跟復制異常的那一點也很像,其實就是把表損壞了.

解決：在復制異常的時候會去做表的修復.

3)最大連接數

• Check_lock ->kill select

問題：如果撥測的時候發現連接跑滿了導致MySQL進不去.

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

• Check_sleep ->reset timeout

問題：另一種是沒有鎖的情況,只是業務單純的sleep?導致連接滿了,這是因為實例規格不同,對最大連接數的設置也是不一樣的.

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

• Reset max_conn

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

解決：可以在這個服務器負載允許的情況下,就是內存容納還夠的情況下擴大它的最大連接數.

4)鎖等待

問題：鎖等待就是發現死鎖以后怎么去做：

• Check_active_conn

解決：一種就是通過活動連接這個最直觀的方法,如果鎖很多的時候活動連接就會很多；

• Check_lock? ->kill select

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

5)極端高負載

• Check_load
• Auto_repair

問題：如果機器負載很高.

解決：平臺會做一些高負載的修復方法,比如看到某一個實例的負載很高,平臺就會判斷MySQL是不是可以通過加索引去解決,如果可以,線上就會自動去加一個索引先修復,運維人員可以在第二天上班時間再去跟進.

三、平臺的總體架構

平臺的總體架構共分為四塊：

1.Web Server

Web Server就是一個可視化的界面,后端提供一些API的服務,例如從主機到從機發起的遷移就是一個常任務,可能需要兩三天的時間.

2.后臺作業系統

常任務里包括數據對比這些東西,有一個作業系統進行管理,負責協調前端或者后端通過API發起的任務到公眾模塊的銜接；

3.功能模塊

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

4.基礎服務組件

• 任務運行agent：AJS
• 性能采集agent：cdb_report
• 異常容災切換：TGW

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

平臺總體架構圖：

 

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4341.html