【DB】有贊資料庫自動化運維實踐之路

一、前言

有贊作為”新零售”的軟體服務供應商，隨著業務的不斷髮展，從第一批幾十家商戶到現在300萬商家，涉及零售，美業，餐飲，自媒體等眾多商家，業務規模以及訪問量爆發式增長。

一方面給後端資料庫帶來的影響是伺服器數量和 DB 例項的資料量出現成倍增加。各種業務需求:快速交付例項，慢查詢優化以及備份恢復管理等都給 DBA 的日常運維支援帶來更高的要求。另一方面最開始以 excel 作為 CMDB 管理資料庫例項的純人肉運維又給高效的資料庫運維帶來阻礙。

本文介紹有贊 DBA 研發的資料庫自動化管理平臺-ZanDB，解決上面的業務方發展中遇到的問題，拋磚引玉，希望能給面臨同樣需求的同行帶來幫助。

（圖1） 整體的 web 介面

二、自動化準備2.1、標準化

從事過大規模化運維的朋友都知道:標準化是規模化，自動化的基礎。在我們開發 MySQL 自動化運維平臺的之前，面臨的主要問題就是各種”不標準”:OS 軟體初始化不統一,軟體目錄結構不標準,配置檔案路徑不標準,主從配置不對稱。於是我們開始著手製定標準:

OS 層面

1、磁碟統一做成 RAID5 模式擴大空間利用率。

2、統一 RAID 卡讀寫策略為 WB，IO 排程策略為 deadline，以及其他 SSD IO 方面的優化。

資料庫層面

1、統一目錄配置，通過埠進行區分，例如 my3306,my3307，在 my3306下面建立對應的資料目錄、日誌目錄、執行檔案目錄，tmp 目錄等。

2、每個例項獨享一個配置檔案，除 server_id , innodb_buffer_pool_size 等引數外其他引數均保持一致。

3、線上環境的 MySQL 軟體目錄和版本保持一致。

有了以上標準和規範，我們花了2個月左右的時間將以前不符合的標準的主機和例項進行改造，並且使用 saltstack 來維護 DB 伺服器基礎的軟體安裝和檔案配置規範。

2.2、ZanDB 的技術棧

ZanDB 系統採用 Python Django + Percona-Toolkit + Agent(servant) + Celery+前端相關(JQuery + Ajax)技術，同時利用了快取 Redis 和 MySQL DB 作為儲存，整套系統採用的技術棧較簡單，實現的功能對於目前來說比較實用。

三、自動化運維之路一期

對於任何具有資料資產的公司而言，資料備份重於一切。由於歷史原因，有贊資料庫的備份是由 shell 指令碼堆砌的，沒有統一的入口來檢視備份結果是成功還是失敗，如果 DBA 對自己維護的資料庫的備份有效性一無所知，出現異常問題需要恢復而又恢復不了的時候，對有贊以及有讚的商家而言會是致命的打擊。

因此，我們第一期的工作是開發 ZanDB 備份監控系統。

它的主要功能:

1、實時檢視備份的執行情況，當前應備份例項個數，已完成例項數，備份失敗的個數。

2、顯示每個備份的耗費時長。

3、檢視過去5天的備份統計資訊，如總個數，大小等。

完成 ZanDB 備份監控系統開發，我們對備份情況情況有了基本的掌握，之後開始著手設計 ZanDB 的二期設計研發工作。

四、自動化運維之路二期

在設計 ZanDB 系統時架構時，我們選擇使用 B/S 架構模式，在資料庫伺服器上部署我們使用 go 自研的 agent—servant，ZanDB 系統通過 http 服務排程 agent 執行各種任務，避免資料庫伺服器通過明文密碼直連 ZanDB 的後設資料庫，增加系統的健壯性和安全性。

總體上我們將 ZanDB 的業務邏輯分成了七部分：後設資料管理,備份管理,例項管理,主機管理,任務管理,日誌管理,日常維護。

（圖2） ZanDB 系統設計邏輯架構

4.1、任務系統

所有的自動化管理平臺中都需要一個核心元件-任務管理系統，主動或者被動進行各種任務排程。我們在 ZanDB 中實現了一個相對健壯的任務排程系統，用於執行例項的備份,後設資料收集,例項維護比如新增從庫，建立主從例項等工作, 該系統支援多種型別的任務：支援按照時間(分鐘，小時，每天，星期，月份)，還支援一定間隔的重複性任務。

該任務系統由資料庫伺服器上的 agent-servant 和下發任務的排程邏輯構成，任務排程的後設資料表中記錄了所有的任務和任務關聯主機的時間策略。通過任務系統，我們徹底的去掉了 DB 主機上的 crontab 指令碼，動態修改任務執行時間、策略以及是否需要執行變得輕而易舉。

（圖3） 任務管理系統

4.2、備份子系統

有讚的資料庫備份是利用 xtrabackup 做物理備份，經過壓縮，然後 rsync 到備份目的機器上，定期遠端備份到異地機房。在一期的基礎上，我們完善了備份系統。

1、使用 python 重構底層備份指令碼，由 db 伺服器上的 agent 執行，新增回撥 api 介面用於設定備份任務的執行狀態，如果一臺主機上存在備份失敗的例項，會傳送報警到 DBA 的手機，DBA 可以直接在備份系統中檢視其備份報錯日誌，執行重試，省去了登入 DB 主機執行的步驟。

2、和任務系統耦合，我們去掉了一期中依賴 crontab 進行備份的定時任務。

3 、通過 ZanDB 系統設定備份時間以及例項是否需要備份，支援動態調整備份的目的機器。

同時，備份系統每天針對核心資料庫的備份執行有效性校驗。如果發現備份校驗失敗，通過告警平臺觸發微信或者簡訊告警，通知 DBA 進行檢查並進行重新備份。

4.3、主機管理

主機後設資料是維護資料庫例項的基礎，包含主機名，ip 地址，機房位置，記憶體，空間大小等核心資訊，在 ZanDB 系統中，我們設定了定時任務通過 Zabbix/open-falcon 的 api 獲取主機資訊，比如磁碟可用空間，記憶體可用空間等定期更新後設資料基本資訊，為分配例項提供準確的資料決策。同時可以做資料庫叢集資料運營，比如預警空間剩餘多少天，為資料庫叢集擴容提供資料判斷。

4.4、例項管理

（圖4） 例項管理功能

為了儘可能的發揮主機的效能，有讚的資料庫採用單機多例項的模式，主機與 DB 例項是一對多的關係。通過例項管理系統，我們可以實現如下功能:

1、檢視當前的例項列表，獲取例項當前的資料大小，日誌大小，主從延遲狀態，慢查個數等等。我們還可以通過例項列表設定例項是否啟用

2、新增單個例項，一對主從，新增一個或者多個從庫。新增例項的過程是通過 rsync 命令遠端備份機或者本地機器上標準的資料庫模板(一個預生成且關閉的mysql例項)，然後用 my.cnf 模板渲染 server_id,buffer_pool_size 等生成標準 my.cnf 配置檔案，執行的具體步驟可以通過 web 介面的流程系統檢視 ，任務排程系統支援部分步驟的失敗重試。

3、例項的主從一致性校驗。在 MySQL 主從複製中，有可能因為主從複製錯誤、主從切換或者應用使用不當等導致主從資料不一致。為了提早發現資料的不一致,ZanDB 每天都針對核心資料庫，進行主從的一致性校驗，避免產生線上影響。

4、例項拆分，用來將之前在同一個例項裡面的多個 schema 拆分到不同的例項裡面。

5、每天將例項的後設資料進行快照，如慢查資料，資料目錄大小等，方便例項的歷史資料分析。

4.5、日誌管理

ZanDB 定義的日誌管理和慢查詢有關，用於維護 slow_log 和 killed_sql，慢查詢日誌大家都瞭解，這裡解釋一下 killed_sql。為了防止例項被慢查拖垮，我們為每個例項啟用類似 pt-killer 的工具 — sql-killer 進行實時監控，將被 kill 的 sql 寫入到具體的指定規則的日誌檔案中。

大多數 DBA 優化的 SQL 路徑是登陸機器，檢視慢查詢日誌，登陸例項，獲取表結構，explain sql，檢查執行計劃。對於規模化的 DB 運維而言，如果只能通過登入每臺 DB 主機才能檢查慢查詢是一件非常痛苦的事情。為了解放 DBA 的雙手，同時更好的發現和優化慢日誌，保障 DB 的穩定性，ZanDB 日誌系統由此誕生，主要做 TopN 展示和慢查分析。

我們在收集例項後設資料的過程中會去統計慢查和被 kill 的 SQL 的記錄數並更新到 ZanDB 的後設資料中，通過頁面展示各個業務中慢查詢最多的 topN。當然我們也設定慢查詢報警閾值，慢查詢超過一定閾值的例項會觸發簡訊報警，及時通知 DBA 和開發關注。

（圖5） 慢查詢系統

有了慢查詢的資料之後如何解決”不在登陸主機檢視慢查 sql”呢？我們的系統每天會將慢查詢日誌做輪轉切割，每天產生一個日誌檔案，ZanDB 通過 agent 呼叫 pt-query-digest 分析指定的慢查日誌並返回給 ZanDB 的頁面端，展示表結構，慢 sql ，對應的執行計劃，以及表的大小資訊。

系統要獲取慢查詳情的時候，通過呼叫 pt-query-digest，分析慢日誌檔案，先將結果存到對應的例項 slow log 裡，系統下次再獲取慢查的時候，如果發現該日期的慢查已經存在分析後的結果，直接返回。同時，日誌管理裡面還包含了被 kill 的 SQL 的 top 情況，和慢查是類似的。

4.6、後設資料管理

（圖6） 分片資訊查詢

後設資料管理包含了 binlog 後設資料、主鍵的溢位校驗，分片資訊資訊等。

binlog 後設資料管理主要記錄每個例項的每個 binlog 起始時間和結束時間，binlog 保留時長，在進行資料恢復的時候可以快速的定位到某個日誌。

通過主鍵溢位校驗，我們可以及時的發現哪些表的主鍵自增已經達到了臨界值，避免因主鍵自增溢位無法插入導致故障。

由於我們商品，交易等核心庫是分庫的，分析慢查，問題定位的時候，需要根據分片鍵找到對應的例項 ip:port。我們開發了一個分片後設資料查詢功能，只要提供資料庫名,表名,分片鍵，就可以快速的定位到一個例項，減少之前人工計算的過程。

4.7、日常維護

（圖7） 日常維護功能介面

日常維護主要是解決部分低頻但是耗時的人肉操作，批量檢視例項的某些引數，批量修改配置，緊急的 binlog 恢復等。

批量執行 SQL 是選擇一批例項，執行維護的 SQL。例如，需要修改記憶體中某個引數的值，或者獲取引數的值。這個 SQL 只允許維護相關的，DML 是不允許執行的。

批量修改配置和執行 SQL 型別的修改配置類似，不同的是，修改配置是會同步變更配置檔案，永久生效，同時也修改記憶體，例如調整慢查時間等。

解析 binlog 是基於開源的 binlog2sql 做的，根據提供的資料庫名稱，表名，時間段，利用binlog 後設資料查到指定的 binlog 進行解析得到文字檔案 可以在網頁檢視和下載，在解決突發的開發誤操作需要緊急恢復過程中特別有效。

4.8、資料運營

ZanDB 從開發落地到現在已經半年多時間了，積累了一定量的例項資料空間大小，記憶體大小等,我們利用這些積累的資料做運營分析，開發了趨勢圖和成本核算功能。

趨勢圖用於展示資料庫總體的空間和記憶體利用率情況，以及核心業務的增長曲線，方便 dba 對機器資源進行調配。

成本核算功能統計各個業務耗費的成本以及佔用比例，為業務層決策提供一定的參考。

4.9、HA 管理

有讚的資料庫高可用經歷了兩個階段。

第一個階段是基於 keepalived + vip 架構的 HA,但是我們也遇到了磁碟 io 抖動導致指令碼檢查失敗切換和基礎網路 arp 廣播限速導致 ha 切換失效的問題。這種方式也不可避免的會有腦裂問題。

第二階段我們自研了基於 go 語言的HA管理工具 hamster。hamster 有強大的叢集管理能力，可以同時維護大量 MySQL 叢集，進行健康檢查，故障切換，主動切換，狀態監控。提供了完整的 Restful API 來管理叢集和例項。

在高可用方面，總體原理上類似 MHA。實現了基於 relay log 解析和基於 GTID 兩種方式來處理 MySQL 故障切換時的資料填補問題。主動切換和故障切換通常在秒級時間內就能完成。高可用體系還結合了我們的 proxy 來控制客戶端訪問。資料庫切換不再使用 vip，避免了之前的 arp 導致的切換失效，也不再受 arp 不能跨網路的限制，為實現有贊 IT 基礎架構雙機房容災打下基礎。

五、展望

目前開發完成的 ZanDB 系統能夠解決70%左右的人肉運維工作，但是距離完全的自動化還是有一定的差距，後續在運維方面還需要實現秒級監控，日誌審計，例項巡檢，例項水平拆分等功能，面向開發方面需要完善資料庫效能診斷，自動分析資料庫慢查等功能。

從使用者使用互動來看，現在的 ZanDB 更多的是給 DBA 用的，但是系統最終服務的物件是業務方或者開發，如何提高系統的有效使用率，在交付和維護使用上給開發帶來收益也是我們要思考和落地的目標。

最後，有讚的業務正在快速發展，我們要走的路還很長，這路上挑戰與機遇並存，我們需要更多優秀的運維人才加入有贊，和我們一起構建穩定，高效的IT基礎設施。