有贊作為”新零售”的軟件服務(wù)供應(yīng)商，隨著業(yè)務(wù)的不斷發(fā)展，從第一批幾十家商戶到現(xiàn)在300萬商家，涉及零售，美業(yè)，餐飲，自媒體等眾多商家，業(yè)務(wù)規(guī)模以及訪問量爆發(fā)式增長。

    一方面給后端數(shù)據(jù)庫帶來的影響是服務(wù)器數(shù)量和 DB 實(shí)例的數(shù)據(jù)量出現(xiàn)成倍增加。各種業(yè)務(wù)需求:快速交付實(shí)例，慢查詢優(yōu)化以及備份恢復(fù)管理等都給 DBA 的日常運(yùn)維支持帶來更高的要求。另一方面最開始以 excel 作為 CMDB 管理數(shù)據(jù)庫實(shí)例的純?nèi)巳膺\(yùn)維又給高效的數(shù)據(jù)庫運(yùn)維帶來阻礙。

    本文介紹有贊 DBA 研發(fā)的數(shù)據(jù)庫自動化管理平臺-ZanDB，解決上面的業(yè)務(wù)方發(fā)展中遇到的問題，拋磚引玉，希望能給面臨同樣需求的同行帶來幫助。

（圖1） 整體的 web 界面

二、自動化準(zhǔn)備2.1、標(biāo)準(zhǔn)化

    從事過大規(guī)模化運(yùn)維的朋友都知道:標(biāo)準(zhǔn)化是規(guī)模化，自動化的基礎(chǔ)。在我們開發(fā) MySQL 自動化運(yùn)維平臺的之前，面臨的主要問題就是各種”不標(biāo)準(zhǔn)”:OS 軟件初始化不統(tǒng)一,軟件目錄結(jié)構(gòu)不標(biāo)準(zhǔn),配置文件路徑不標(biāo)準(zhǔn),主從配置不對稱。于是我們開始著手制定標(biāo)準(zhǔn):

OS 層面

1、磁盤統(tǒng)一做成 RAID5 模式擴(kuò)大空間利用率。

2、統(tǒng)一 RAID 卡讀寫策略為 WB，IO 調(diào)度策略為 deadline，以及其他 SSD IO 方面的優(yōu)化。

數(shù)據(jù)庫層面

1、統(tǒng)一目錄配置，通過端口進(jìn)行區(qū)分，例如 my3306,my3307，在 my3306下面創(chuàng)建對應(yīng)的數(shù)據(jù)目錄、日志目錄、運(yùn)行文件目錄，tmp 目錄等。

2、每個(gè)實(shí)例獨(dú)享一個(gè)配置文件，除 server_id , innodb_buffer_pool_size 等參數(shù)外其他參數(shù)均保持一致。

3、線上環(huán)境的 MySQL 軟件目錄和版本保持一致。

    有了以上標(biāo)準(zhǔn)和規(guī)范，我們花了2個(gè)月左右的時(shí)間將以前不符合的標(biāo)準(zhǔn)的主機(jī)和實(shí)例進(jìn)行改造，并且使用 saltstack 來維護(hù) DB 服務(wù)器基礎(chǔ)的軟件安裝和文件配置規(guī)范。

2.2、ZanDB 的技術(shù)棧

    ZanDB 系統(tǒng)采用 Python Django + Percona-Toolkit + Agent(servant) + Celery+前端相關(guān)(JQuery + Ajax)技術(shù)，同時(shí)利用了緩存 Redis 和 MySQL DB 作為存儲，整套系統(tǒng)采用的技術(shù)棧較簡單，實(shí)現(xiàn)的功能對于目前來說比較實(shí)用。

三、自動化運(yùn)維之路一期

    對于任何具有數(shù)據(jù)資產(chǎn)的公司而言，數(shù)據(jù)備份重于一切。由于歷史原因，有贊數(shù)據(jù)庫的備份是由 shell 腳本堆砌的，沒有統(tǒng)一的入口來查看備份結(jié)果是成功還是失敗，如果 DBA 對自己維護(hù)的數(shù)據(jù)庫的備份有效性一無所知，出現(xiàn)異常問題需要恢復(fù)而又恢復(fù)不了的時(shí)候，對有贊以及有贊的商家而言會是致命的打擊。

    因此，我們第一期的工作是開發(fā) ZanDB 備份監(jiān)控系統(tǒng)。

    它的主要功能:

1、實(shí)時(shí)查看備份的執(zhí)行情況，當(dāng)前應(yīng)備份實(shí)例個(gè)數(shù)，已完成實(shí)例數(shù)，備份失敗的個(gè)數(shù)。

2、顯示每個(gè)備份的耗費(fèi)時(shí)長。

3、查看過去5天的備份統(tǒng)計(jì)信息，如總個(gè)數(shù)，大小等。

    完成 ZanDB 備份監(jiān)控系統(tǒng)開發(fā)，我們對備份情況情況有了基本的掌握，之后開始著手設(shè)計(jì) ZanDB 的二期設(shè)計(jì)研發(fā)工作。

四、自動化運(yùn)維之路二期

    在設(shè)計(jì) ZanDB 系統(tǒng)時(shí)架構(gòu)時(shí)，我們選擇使用 B/S 架構(gòu)模式，在數(shù)據(jù)庫服務(wù)器上部署我們使用 go 自研的 agent—servant，ZanDB 系統(tǒng)通過 http 服務(wù)調(diào)度 agent 執(zhí)行各種任務(wù)，避免數(shù)據(jù)庫服務(wù)器通過明文密碼直連 ZanDB 的元數(shù)據(jù)庫，增加系統(tǒng)的健壯性和安全性。

    總體上我們將 ZanDB 的業(yè)務(wù)邏輯分成了七部分：元數(shù)據(jù)管理,備份管理,實(shí)例管理,主機(jī)管理,任務(wù)管理,日志管理,日常維護(hù)。

（圖2） ZanDB 系統(tǒng)設(shè)計(jì)邏輯架構(gòu)

4.1、任務(wù)系統(tǒng)

    所有的自動化管理平臺中都需要一個(gè)核心組件-任務(wù)管理系統(tǒng)，主動或者被動進(jìn)行各種任務(wù)調(diào)度。我們在 ZanDB 中實(shí)現(xiàn)了一個(gè)相對健壯的任務(wù)調(diào)度系統(tǒng)，用于執(zhí)行實(shí)例的備份,元數(shù)據(jù)收集,實(shí)例維護(hù)比如添加從庫，創(chuàng)建主從實(shí)例等工作, 該系統(tǒng)支持多種類型的任務(wù)：支持按照時(shí)間(分鐘，小時(shí)，每天，星期，月份)，還支持一定間隔的重復(fù)性任務(wù)。

    該任務(wù)系統(tǒng)由數(shù)據(jù)庫服務(wù)器上的 agent-servant 和下發(fā)任務(wù)的調(diào)度邏輯構(gòu)成，任務(wù)調(diào)度的元數(shù)據(jù)表中記錄了所有的任務(wù)和任務(wù)關(guān)聯(lián)主機(jī)的時(shí)間策略。通過任務(wù)系統(tǒng)，我們徹底的去掉了 DB 主機(jī)上的 crontab 腳本，動態(tài)修改任務(wù)執(zhí)行時(shí)間、策略以及是否需要執(zhí)行變得輕而易舉。

（圖3） 任務(wù)管理系統(tǒng)

4.2、備份子系統(tǒng)

    有贊的數(shù)據(jù)庫備份是利用 xtrabackup 做物理備份，經(jīng)過壓縮，然后 rsync 到備份目的機(jī)器上，定期遠(yuǎn)程備份到異地機(jī)房。在一期的基礎(chǔ)上，我們完善了備份系統(tǒng)。

1、使用 python 重構(gòu)底層備份腳本，由 db 服務(wù)器上的 agent 執(zhí)行，添加回調(diào) api 接口用于設(shè)置備份任務(wù)的運(yùn)行狀態(tài)，如果一臺主機(jī)上存在備份失敗的實(shí)例，會發(fā)送報(bào)警到 DBA 的手機(jī)，DBA 可以直接在備份系統(tǒng)中查看其備份報(bào)錯(cuò)日志，執(zhí)行重試，省去了登錄 DB 主機(jī)執(zhí)行的步驟。

2、和任務(wù)系統(tǒng)耦合，我們?nèi)サ袅艘黄谥幸蕾?crontab 進(jìn)行備份的定時(shí)任務(wù)。

3 、通過 ZanDB 系統(tǒng)設(shè)置備份時(shí)間以及實(shí)例是否需要備份，支持動態(tài)調(diào)整備份的目的機(jī)器。

    同時(shí)，備份系統(tǒng)每天針對核心數(shù)據(jù)庫的備份執(zhí)行有效性校驗(yàn)。如果發(fā)現(xiàn)備份校驗(yàn)失敗，通過告警平臺觸發(fā)微信或者短信告警，通知 DBA 進(jìn)行檢查并進(jìn)行重新備份。

4.3、主機(jī)管理

    主機(jī)元數(shù)據(jù)是維護(hù)數(shù)據(jù)庫實(shí)例的基礎(chǔ)，包含主機(jī)名，ip 地址，機(jī)房位置，內(nèi)存，空間大小等核心信息，在 ZanDB 系統(tǒng)中，我們設(shè)置了定時(shí)任務(wù)通過 Zabbix/open-falcon 的 api 獲取主機(jī)信息，比如磁盤可用空間，內(nèi)存可用空間等定期更新元數(shù)據(jù)基本信息，為分配實(shí)例提供準(zhǔn)確的數(shù)據(jù)決策。同時(shí)可以做數(shù)據(jù)庫集群數(shù)據(jù)運(yùn)營，比如預(yù)警空間剩余多少天，為數(shù)據(jù)庫集群擴(kuò)容提供數(shù)據(jù)判斷。

4.4、實(shí)例管理

（圖4） 實(shí)例管理功能

為了盡可能的發(fā)揮主機(jī)的性能，有贊的數(shù)據(jù)庫采用單機(jī)多實(shí)例的模式，主機(jī)與 DB 實(shí)例是一對多的關(guān)系。通過實(shí)例管理系統(tǒng)，我們可以實(shí)現(xiàn)如下功能:

1、查看當(dāng)前的實(shí)例列表，獲取實(shí)例當(dāng)前的數(shù)據(jù)大小，日志大小，主從延遲狀態(tài)，慢查個(gè)數(shù)等等。我們還可以通過實(shí)例列表設(shè)置實(shí)例是否啟用

2、新增單個(gè)實(shí)例，一對主從，添加一個(gè)或者多個(gè)從庫。新增實(shí)例的過程是通過 rsync 命令遠(yuǎn)程備份機(jī)或者本地機(jī)器上標(biāo)準(zhǔn)的數(shù)據(jù)庫模板(一個(gè)預(yù)生成且關(guān)閉的mysql實(shí)例)，然后用 my.cnf 模板渲染 server_id,buffer_pool_size 等生成標(biāo)準(zhǔn) my.cnf 配置文件，執(zhí)行的具體步驟可以通過 web 界面的流程系統(tǒng)查看 ，任務(wù)調(diào)度系統(tǒng)支持部分步驟的失敗重試。

3、實(shí)例的主從一致性校驗(yàn)。在 MySQL 主從復(fù)制中，有可能因?yàn)橹鲝膹?fù)制錯(cuò)誤、主從切換或者應(yīng)用使用不當(dāng)?shù)葘?dǎo)致主從數(shù)據(jù)不一致。為了提早發(fā)現(xiàn)數(shù)據(jù)的不一致,ZanDB 每天都針對核心數(shù)據(jù)庫，進(jìn)行主從的一致性校驗(yàn)，避免產(chǎn)生線上影響。

4、實(shí)例拆分，用來將之前在同一個(gè)實(shí)例里面的多個(gè) schema 拆分到不同的實(shí)例里面。

5、每天將實(shí)例的元數(shù)據(jù)進(jìn)行快照，如慢查數(shù)據(jù)，數(shù)據(jù)目錄大小等，方便實(shí)例的歷史數(shù)據(jù)分析。

4.5、日志管理

    ZanDB 定義的日志管理和慢查詢有關(guān)，用于維護(hù) slow_log 和 killed_sql，慢查詢?nèi)罩敬蠹叶剂私猓@里解釋一下 killed_sql。為了防止實(shí)例被慢查拖垮，我們?yōu)槊總€(gè)實(shí)例啟用類似 pt-killer 的工具 — sql-killer 進(jìn)行實(shí)時(shí)監(jiān)控，將被 kill 的 sql 寫入到具體的指定規(guī)則的日志文件中。

    大多數(shù) DBA 優(yōu)化的 SQL 路徑是登陸機(jī)器，查看慢查詢?nèi)罩荆顷憣?shí)例，獲取表結(jié)構(gòu)，explain sql，檢查執(zhí)行計(jì)劃。對于規(guī)模化的 DB 運(yùn)維而言，如果只能通過登錄每臺 DB 主機(jī)才能檢查慢查詢是一件非常痛苦的事情。為了解放 DBA 的雙手，同時(shí)更好的發(fā)現(xiàn)和優(yōu)化慢日志，保障 DB 的穩(wěn)定性，ZanDB 日志系統(tǒng)由此誕生，主要做 TopN 展示和慢查分析。

    我們在收集實(shí)例元數(shù)據(jù)的過程中會去統(tǒng)計(jì)慢查和被 kill 的 SQL 的記錄數(shù)并更新到 ZanDB 的元數(shù)據(jù)中，通過頁面展示各個(gè)業(yè)務(wù)中慢查詢最多的 topN。當(dāng)然我們也設(shè)定慢查詢報(bào)警閾值，慢查詢超過一定閾值的實(shí)例會觸發(fā)短信報(bào)警，及時(shí)通知 DBA 和開發(fā)關(guān)注。

（圖5） 慢查詢系統(tǒng)

    有了慢查詢的數(shù)據(jù)之后如何解決”不在登陸主機(jī)查看慢查 sql”呢？我們的系統(tǒng)每天會將慢查詢?nèi)罩咀鲚嗈D(zhuǎn)切割，每天產(chǎn)生一個(gè)日志文件，ZanDB 通過 agent 調(diào)用 pt-query-digest 分析指定的慢查日志并返回給 ZanDB 的頁面端，展示表結(jié)構(gòu)，慢 sql ，對應(yīng)的執(zhí)行計(jì)劃，以及表的大小信息。

    系統(tǒng)要獲取慢查詳情的時(shí)候，通過調(diào)用 pt-query-digest，分析慢日志文件，先將結(jié)果存到對應(yīng)的實(shí)例 slow log 里，系統(tǒng)下次再獲取慢查的時(shí)候，如果發(fā)現(xiàn)該日期的慢查已經(jīng)存在分析后的結(jié)果，直接返回。同時(shí)，日志管理里面還包含了被 kill 的 SQL 的 top 情況，和慢查是類似的。

4.6、元數(shù)據(jù)管理

（圖6） 分片信息查詢

    元數(shù)據(jù)管理包含了 binlog 元數(shù)據(jù)、主鍵的溢出校驗(yàn)，分片信息信息等。

    binlog 元數(shù)據(jù)管理主要記錄每個(gè)實(shí)例的每個(gè) binlog 起始時(shí)間和結(jié)束時(shí)間，binlog 保留時(shí)長，在進(jìn)行數(shù)據(jù)恢復(fù)的時(shí)候可以快速的定位到某個(gè)日志。

    通過主鍵溢出校驗(yàn)，我們可以及時(shí)的發(fā)現(xiàn)哪些表的主鍵自增已經(jīng)達(dá)到了臨界值，避免因主鍵自增溢出無法插入導(dǎo)致故障。

    由于我們商品，交易等核心庫是分庫的，分析慢查，問題定位的時(shí)候，需要根據(jù)分片鍵找到對應(yīng)的實(shí)例 ip:port。我們開發(fā)了一個(gè)分片元數(shù)據(jù)查詢功能，只要提供數(shù)據(jù)庫名,表名,分片鍵，就可以快速的定位到一個(gè)實(shí)例，減少之前人工計(jì)算的過程。

4.7、日常維護(hù)

（圖7） 日常維護(hù)功能界面

    日常維護(hù)主要是解決部分低頻但是耗時(shí)的人肉操作，批量查看實(shí)例的某些參數(shù)，批量修改配置，緊急的 binlog 恢復(fù)等。

    批量執(zhí)行 SQL 是選擇一批實(shí)例，執(zhí)行維護(hù)的 SQL。例如，需要修改內(nèi)存中某個(gè)參數(shù)的值，或者獲取參數(shù)的值。這個(gè) SQL 只允許維護(hù)相關(guān)的，DML 是不允許執(zhí)行的。

    批量修改配置和執(zhí)行 SQL 類型的修改配置類似，不同的是，修改配置是會同步變更配置文件，永久生效，同時(shí)也修改內(nèi)存，例如調(diào)整慢查時(shí)間等。

    解析 binlog 是基于開源的 binlog2sql 做的，根據(jù)提供的數(shù)據(jù)庫名稱，表名，時(shí)間段，利用binlog 元數(shù)據(jù)查到指定的 binlog 進(jìn)行解析得到文本文件 可以在網(wǎng)頁查看和下載，在解決突發(fā)的開發(fā)誤操作需要緊急恢復(fù)過程中特別有效。

4.8、數(shù)據(jù)運(yùn)營

    ZanDB 從開發(fā)落地到現(xiàn)在已經(jīng)半年多時(shí)間了，積累了一定量的實(shí)例數(shù)據(jù)空間大小，內(nèi)存大小等,我們利用這些積累的數(shù)據(jù)做運(yùn)營分析，開發(fā)了趨勢圖和成本核算功能。

    趨勢圖用于展示數(shù)據(jù)庫總體的空間和內(nèi)存利用率情況，以及核心業(yè)務(wù)的增長曲線，方便 dba 對機(jī)器資源進(jìn)行調(diào)配。

    成本核算功能統(tǒng)計(jì)各個(gè)業(yè)務(wù)耗費(fèi)的成本以及占用比例，為業(yè)務(wù)層決策提供一定的參考。

4.9、HA 管理

    有贊的數(shù)據(jù)庫高可用經(jīng)歷了兩個(gè)階段。

    第一個(gè)階段是基于 keepalived + vip 架構(gòu)的 HA,但是我們也遇到了磁盤 io 抖動導(dǎo)致腳本檢查失敗切換和基礎(chǔ)網(wǎng)絡(luò) arp 廣播限速導(dǎo)致 ha 切換失效的問題。這種方式也不可避免的會有腦裂問題。

    第二階段我們自研了基于 go 語言的HA管理工具 hamster。hamster 有強(qiáng)大的集群管理能力，可以同時(shí)維護(hù)大量 MySQL 集群，進(jìn)行健康檢查，故障切換，主動切換，狀態(tài)監(jiān)控。提供了完整的 Restful API 來管理集群和實(shí)例。

    在高可用方面，總體原理上類似 MHA。實(shí)現(xiàn)了基于 relay log 解析和基于 GTID 兩種方式來處理 MySQL 故障切換時(shí)的數(shù)據(jù)填補(bǔ)問題。主動切換和故障切換通常在秒級時(shí)間內(nèi)就能完成。高可用體系還結(jié)合了我們的 proxy 來控制客戶端訪問。數(shù)據(jù)庫切換不再使用 vip，避免了之前的 arp 導(dǎo)致的切換失效，也不再受 arp 不能跨網(wǎng)絡(luò)的限制，為實(shí)現(xiàn)有贊 IT 基礎(chǔ)架構(gòu)雙機(jī)房容災(zāi)打下基礎(chǔ)。

五、展望

    目前開發(fā)完成的 ZanDB 系統(tǒng)能夠解決70%左右的人肉運(yùn)維工作，但是距離完全的自動化還是有一定的差距，后續(xù)在運(yùn)維方面還需要實(shí)現(xiàn)秒級監(jiān)控，日志審計(jì)，實(shí)例巡檢，實(shí)例水平拆分等功能，面向開發(fā)方面需要完善數(shù)據(jù)庫性能診斷，自動分析數(shù)據(jù)庫慢查等功能。

    從用戶使用交互來看，現(xiàn)在的 ZanDB 更多的是給 DBA 用的，但是系統(tǒng)最終服務(wù)的對象是業(yè)務(wù)方或者開發(fā)，如何提高系統(tǒng)的有效使用率，在交付和維護(hù)使用上給開發(fā)帶來收益也是我們要思考和落地的目標(biāo)。

    最后，有贊的業(yè)務(wù)正在快速發(fā)展，我們要走的路還很長，這路上挑戰(zhàn)與機(jī)遇并存，我們需要更多優(yōu)秀的運(yùn)維人才加入有贊，和我們一起構(gòu)建穩(wěn)定，高效的IT基礎(chǔ)設(shè)施。