運維的福音，深度剖析騰訊雲自動運維平臺

嘉賓介紹：祝海強，騰訊高級工程師。8年數據庫經歷，曾就任於第九城市、返利網任高級DBA。目前負責騰訊雲CDB for MySQL運維團隊，對MySQL、MSSQL等數據庫運維、調優診斷具備豐富的經驗。

1、自動運維平臺的做用

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.擴容/縮容

因爲騰訊雲正在飛速發展，目前大概已有六萬多的實例，靠人工去進行升級實例、遷移、切換是沒法支持的，因此引入了自動化的運維平臺。微信紅包就是一個典型的例子，春節的量很是大，一擴容可能就是上千臺機器，而過完年之後就須要縮容。這些工做量都是很是大的。

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是否是能夠經過加索引去解決，若是能夠，線上就會自動去加一個索引先修復，運維人員能夠在次日上班時間再去跟進。

3、平臺的整體架構

平臺的整體架構共分爲四塊：

1.Web Server

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

2.後臺做業系統

常任務裏包括數據對比這些東西，有一個做業系統進行管理，負責協調前端或者後端經過API發起的任務到公衆模塊的銜接；

3.功能模塊

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

4.基礎服務組件

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

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

平臺整體架構圖：