有贊數據庫自動化運維實踐之路

1、前言

有贊做爲」新零售」的軟件服務供應商，隨着業務的不斷髮展，從第一批幾十家商戶到如今300萬商家，涉及零售，美業，餐飲，自媒體等衆多商家，業務規模以及訪問量爆發式增加。

一方面給後端數據庫帶來的影響是服務器數量和 DB 實例的數據量出現成倍增長。各類業務需求:快速交付實例，慢查詢優化以及備份恢復管理等都給 DBA 的平常運維支持帶來更高的要求。另外一方面最開始以 excel 做爲 CMDB 管理數據庫實例的純人肉運維又給高效的數據庫運維帶來阻礙。

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

（圖1） 總體的 web 界面

2、自動化準備

2.一、標準化

從事過大規模化運維的朋友都知道:標準化是規模化，自動化的基礎。在咱們開發 MySQL 自動化運維平臺的以前，面臨的主要問題就是各類」不標準」:OS 軟件初始化不統一,軟件目錄結構不標準,配置文件路徑不標準,主從配置不對稱。因而咱們開始着手製定標準:

OS 層面

一、磁盤統一作成 RAID5 模式擴大空間利用率。

二、統一 RAID 卡讀寫策略爲 WB，IO 調度策略爲 deadline，以及其餘 SSD IO 方面的優化。

數據庫層面

一、統一目錄配置，經過端口進行區分，例如 my3306,my3307，在 my3306下面建立對應的數據目錄、日誌目錄、運行文件目錄，tmp 目錄等。

二、每一個實例獨享一個配置文件，除 server_id , innodb_buffer_pool_size 等參數外其餘參數均保持一致。

三、線上環境的 MySQL 軟件目錄和版本保持一致。
有了以上標準和規範，咱們花了2個月左右的時間將之前不符合的標準的主機和實例進行改造，而且使用 saltstack 來維護 DB 服務器基礎的軟件安裝和文件配置規範。

2.二、ZanDB 的技術棧

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

3、自動化運維之路一期

對於任何具備數據資產的公司而言，數據備份重於一切。因爲歷史緣由，有贊數據庫的備份是由 shell 腳本堆砌的，沒有統一的入口來查看備份結果是成功仍是失敗，若是 DBA 對本身維護的數據庫的備份有效性一無所知，出現異常問題須要恢復而又恢復不了的時候，對有贊以及有讚的商家而言會是致命的打擊。

所以，咱們第一期的工做是開發 ZanDB 備份監控系統。

它的主要功能:

一、實時查看備份的執行狀況，當前應備份實例個數，已完成實例數，備份失敗的個數。

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

三、查看過去5天的備份統計信息，如總個數，大小等。

完成 ZanDB 備份監控系統開發，咱們對備份狀況狀況有了基本的掌握，以後開始着手設計 ZanDB 的二期設計研發工做。

4、自動化運維之路二期

在設計 ZanDB 系統時架構時，咱們選擇使用 B/S 架構模式，在數據庫服務器上部署咱們使用 go 自研的 agent—servant，ZanDB 系統經過 http 服務調度 agent 執行各類任務，避免數據庫服務器經過明文密碼直連 ZanDB 的元數據庫，增長系統的健壯性和安全性。

整體上咱們將 ZanDB 的業務邏輯分紅了七部分：元數據管理,備份管理,實例管理,主機管理,任務管理,日誌管理,平常維護。

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

4.一、任務系統

全部的自動化管理平臺中都須要一個核心組件-任務管理系統，主動或者被動進行各類任務調度。咱們在 ZanDB 中實現了一個相對健壯的任務調度系統，用於執行實例的備份,元數據收集,實例維護好比添加從庫，建立主從實例等工做, 該系統支持多種類型的任務：支持按照時間(分鐘，小時，天天，星期，月份)，還支持必定間隔的重複性任務。

該任務系統由數據庫服務器上的 agent-servant 和下發任務的調度邏輯構成，任務調度的元數據表中記錄了全部的任務和任務關聯主機的時間策略。經過任務系統，咱們完全的去掉了 DB 主機上的 crontab 腳本，動態修改任務執行時間、策略以及是否須要執行變得垂手可得。

（圖3） 任務管理系統

4.二、備份子系統

有讚的數據庫備份是利用 xtrabackup 作物理備份，通過壓縮，而後 rsync 到備份目的機器上，按期遠程備份到異地機房。在一期的基礎上，咱們完善了備份系統。

一、使用 python 重構底層備份腳本，由 db 服務器上的 agent 執行，添加回調 api 接口用於設置備份任務的運行狀態，若是一臺主機上存在備份失敗的實例，會發送報警到 DBA 的手機，DBA 能夠直接在備份系統中查看其備份報錯日誌，執行重試，省去了登陸 DB 主機執行的步驟。

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

3 、經過 ZanDB 系統設置備份時間以及實例是否須要備份，支持動態調整備份的目的機器。

同時，備份系統天天針對核心數據庫的備份執行有效性校驗。若是發現備份校驗失敗，經過告警平臺觸發微信或者短信告警，通知 DBA 進行檢查並進行從新備份。

4.三、主機管理

主機元數據是維護數據庫實例的基礎，包含主機名，ip 地址，機房位置，內存，空間大小等核心信息，在 ZanDB 系統中，咱們設置了定時任務經過 Zabbix/open-falcon 的 api 獲取主機信息，好比磁盤可用空間，內存可用空間等按期更新元數據基本信息，爲分配實例提供準確的數據決策。同時能夠作數據庫集羣數據運營，好比預警空間剩餘多少天，爲數據庫集羣擴容提供數據判斷。

4.四、實例管理

（圖4） 實例管理功能

爲了儘量的發揮主機的性能，有讚的數據庫採用單機多實例的模式，主機與 DB 實例是一對多的關係。經過實例管理系統，咱們能夠實現以下功能:

一、查看當前的實例列表，獲取實例當前的數據大小，日誌大小，主從延遲狀態，慢查個數等等。咱們還能夠經過實例列表設置實例是否啓用

二、新增單個實例，一對主從，添加一個或者多個從庫。新增實例的過程是經過 rsync 命令遠程備份機或者本地機器上標準的數據庫模板(一個預生成且關閉的mysql實例)，而後用 my.cnf 模板渲染 server_id,buffer_pool_size 等生成標準 my.cnf 配置文件，執行的具體步驟能夠經過 web 界面的流程系統查看 ，任務調度系統支持部分步驟的失敗重試。

三、實例的主從一致性校驗。在 MySQL 主從複製中，有可能由於主從複製錯誤、主從切換或者應用使用不當等致使主從數據不一致。爲了提前發現數據的不一致,ZanDB 天天都針對核心數據庫，進行主從的一致性校驗，避免產生線上影響。

四、實例拆分，用來將以前在同一個實例裏面的多個 schema 拆分到不一樣的實例裏面。

五、天天將實例的元數據進行快照，如慢查數據，數據目錄大小等，方便實例的歷史數據分析。

4.五、日誌管理

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） 分片信息查詢

元數據管理包含了 binlog 元數據、主鍵的溢出校驗，分片信息信息等。

binlog 元數據管理主要記錄每一個實例的每一個 binlog 起始時間和結束時間，binlog 保留時長，在進行數據恢復的時候能夠快速的定位到某個日誌。

經過主鍵溢出校驗，咱們能夠及時的發現哪些表的主鍵自增已經達到了臨界值，避免因主鍵自增溢出沒法插入致使故障。

因爲咱們商品，交易等核心庫是分庫的，分析慢查，問題定位的時候，須要根據分片鍵找到對應的實例 ip:port。咱們開發了一個分片元數據查詢功能，只要提供數據庫名,表名,分片鍵，就能夠快速的定位到一個實例，減小以前人工計算的過程。

4.七、平常維護

（圖7） 平常維護功能界面

平常維護主要是解決部分低頻可是耗時的人肉操做，批量查看實例的某些參數，批量修改配置，緊急的 binlog 恢復等。

批量執行 SQL 是選擇一批實例，執行維護的 SQL。例如，須要修改內存中某個參數的值，或者獲取參數的值。這個 SQL 只容許維護相關的，DML 是不容許執行的。

批量修改配置和執行 SQL 類型的修改配置相似，不一樣的是，修改配置是會同步變動配置文件，永久生效，同時也修改內存，例如調整慢查時間等。

解析 binlog 是基於開源的 binlog2sql 作的，根據提供的數據庫名稱，表名，時間段，利用binlog 元數據查到指定的 binlog 進行解析獲得文本文件 能夠在網頁查看和下載，在解決突發的開發誤操做須要緊急恢復過程當中特別有效。

4.八、數據運營

ZanDB 從開發落地到如今已經半年多時間了，積累了必定量的實例數據空間大小，內存大小等,咱們利用這些積累的數據作運營分析，開發了趨勢圖和成本覈算功能。

趨勢圖用於展現數據庫整體的空間和內存利用率狀況，以及核心業務的增加曲線，方便 dba 對機器資源進行調配。

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

4.九、HA 管理

有讚的數據庫高可用經歷了兩個階段。

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

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

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

5、展望

目前開發完成的 ZanDB 系統可以解決70%左右的人肉運維工做，可是距離徹底的自動化仍是有必定的差距，後續在運維方面還須要實現秒級監控，日誌審計，實例巡檢，實例水平拆分等功能，面向開發方面須要完善數據庫性能診斷，自動分析數據庫慢查等功能。

從用戶使用交互來看，如今的 ZanDB 更多的是給 DBA 用的，可是系統最終服務的對象是業務方或者開發，如何提升系統的有效使用率，在交付和維護使用上給開發帶來收益也是咱們要思考和落地的目標。