有贊 MySQL 自動化運維之路 — ZanDB

轉自：https://tech.youzan.com/youzan-mysql-auto-ops-road/

 

1、前言

在互聯網時代，業務規模經常出現爆發式的增加。快速的實例交付，數據庫優化以及備份管理等任務都對DBA產生了更高的要求，單純的憑藉記憶力去管理那幾十套DB已經再也不適用。那麼如何去批量管理這些實例的備份、元數據、定時腳本和快速實例交付就成了急需解決的的問題。

2、數據庫的標準化

在實現MySQL的自動化運維的過程當中，最痛苦的無非是目錄的不統一，配置文件的混亂以及DB主機的不標準，而這些不標準的環境會讓自動化運維的路途荊棘重重。因此首先咱們將相應的DB主機以及目錄作了標準化，將之前不符合的標準的主機和實例進行改造。

1. 一臺機子上全部實例，都是在統一的目錄下，經過端口進行區分，例如my3306,my3307。而後在my3306下面建立對應的數據目錄、日誌目錄、運行文件目錄等
2. 每一個實例獨享一個配置文件，除serverid , bufferpool_size等參數外其餘參數保持一致
3. 線上環境的MySQL軟件目錄和版本保持一致

3、自動化運維之路一期

在一開始的時候，咱們須要着手解決目前的最要緊的事情：備份。對於DBA來講，備份重於一切。若是DBA對本身維護的數據庫的備份狀況都一無所知，那麼總有一天，你會遭遇數據丟失的災難。所以，咱們開始第一期的工做，ZanDB 備份監控系統。 它實現的主要功能是：

1. 實時查看備份的狀況，當前應備份實例個數，已完成實例數
2. 顯示每一個備份的耗費時長
3. 查看過去5天的備份統計信息，如總個數，大小等

4、自動化運維之路二期

在實現了ZanDB備份監控系統以後，咱們着手開始設計ZanDB 的二期設計研發工做。

在設計ZanDB的過程當中，咱們將主要功能分紅了七部分：備份管理，實例管理，主機管理，任務管理，元數據管理，日誌管理，平常維護。

一、任務系統

爲了實現實例的備份、元數據、定時腳本等工做，必需要有一個健壯的任務調度系統。該任務系統支持多種類型的任務：天天的定時任務，每一個星期的定時任務，每月的定時任務，還支持必定間隔的重複性任務。

該任務系統由一個執行任務的agent和下發任務的調度系統完成，任務調度系統中記錄了全部的任務和任務下主機的時間策略。

經過任務系統，咱們完全的去掉了db主機上的crontab 腳本，修改任務執行時間、策略以及是否須要執行變得垂手可得。

二、備份管理

在一期的基礎上，咱們完善了備份系統。經過和任務系統相結合，能夠輕鬆的設置備份的時間以及備份的實例，是否須要備份等，保證了在業務低峯期執行備份操做。

備份操做由agent執行，備份成功失敗經過相應的回調地址設置狀態。若是一臺主機上存在備份失敗的實例，能夠直接在備份系統中查看其備份報錯日誌，執行重試，省去了頻繁登陸DB主機的痛苦。

同時，備份系統天天針對核心數據庫的備份執行校驗操做。若是發現備份校驗失敗，經過告警平臺觸發微信或者短信的告警，方便維護人員第一時間知道是否存在備份失效的狀況。

三、主機管理

主機的元數據是數據庫實例的基礎。在進行主機新增的時候，ZanDB 可以自動的鏈接Zabbix 獲取主機信息，例如磁盤大小，磁盤可用空間，內存可用空間等。

四、實例管理

爲了儘量的發揮主機的性能，咱們在一臺主機上部署了多個實例，所以主機和實例是一對多的關係。

經過實例管理系統，咱們能夠實現以下功能：

1. 查看當前的實例列表，獲取實例當前的數據大小，日誌大小，主從狀態，是否存在慢查，被kill的SQL，實例歷史信息性能信息等等。
2. 新增單個實例，一對實例，針對一個實例/一對主從添加從庫。新增實例的過程是經過rsync 標準的數據庫模板，而後用my.cnf模板渲染生成標準my.cnf配置文件，執行的具體步驟能夠經過流程系統查看 ，支持失敗重試。
3. 實例的主從校驗。在MySQL主從複製中，有可能由於主從複製錯誤、主從切換或者軟件的BUG等致使主從數據不一致。爲了提前發現數據的不一致，就須要天天都針對核心數據庫，進行主從的一致性校驗，避免產生線上影響。
4. 實例拆分，用來將以前在同一個實例裏面的多個schema 拆分到不一樣的實例裏面
5. 天天將實例的元數據進行快照，如慢查數據，數據目錄大小等，方便實例的歷史數據分析。

五、日誌管理

數據庫運行最多的就是SQL，優化SQL是DBA的職責。面對那麼多的實例，若是沒有一個日誌系統，只能經過登陸每臺DB主機去發現慢查將是一件很是痛苦的事情。爲了解放DBA的雙手，同時更好的發現和優化慢日誌，保證DB的穩定性，ZanDB 日誌系統由此誕生。

首先實例元數據收集的過程當中，會統計慢查和被kill的SQL的數據，而後更新到實例的元數據中。經過實例元數據的慢查信息，獲取昨日的TOP 慢查。

那麼如何去獲取慢查呢？固然要經過偉大的agent去獲取慢查日誌。慢查在天天都會進行rotate，產生一個新的慢日誌文件。系統要獲取慢查詳情的時候，經過調用pt-query-digest，分析慢日誌文件，將結果緩存起來，進行返回。系統下次再獲取慢查的時候，若是發現該日期的慢查已經存在分析後的結果，直接返回。

同時，日誌管理裏面還包含了被kill的SQL的top狀況，和慢查是相似的。

六、元數據管理

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

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

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

因爲交易等核心庫數據量很是大，分析慢查等相關信息的時候，須要根據分片鍵找到對應的實例。咱們開發了一個分片元數據查詢功能，只要提供數據庫名、分片id和分片數量，就能夠快速的定位到一個實例，大大的方便了DBA，實現了問題的快速定位。

七、平常維護

平常維護主要是經過agent執行，包括了批量執行SQL，批量修改配置等。

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

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

5、展望

整套ZanDB 系統是採用了Python Django + Percona-Toolkit + Agent + 前端相關技術，同時利用了緩存Redis 和 MySQL 後端DB，整套系統採用的技術棧較簡單，實現的功能對於目前來講比較實用。後續會加入數據庫性能診斷，自動分析數據庫慢查，獲取關鍵信息，自動化拆庫等功能。相信隨着自動化的深刻，DBA的手動重複操做將愈來愈少，將有限的時間投入到更有價值的事情上去。

 
如無特殊說明，本文版權歸 本文做者及有贊技術團隊 全部，採用 署名-非商業性使用 4.0 國際許可協議 進行許可。
轉載請註明：來自有贊技術團隊博客 http://tech.youzan.com/youzan-mysql-auto-ops-road/