祝海強，騰訊高階工程師。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)。

平臺總體架構圖：