有贊作為”新零售”的軟件服務供應商，隨著業務的不斷發展，從第一批幾十家商戶到現在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基礎設施。