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

楊奇龍發表於2017-09-29

一、前言

在網際網路時代,業務規模常常出現爆發式的增長。快速的例項交付,資料庫最佳化以及備份管理等任務都對DBA產生了更高的要求,單純的憑藉記憶力去管理那幾十套DB已經不再適用。那麼如何去批次管理這些例項的備份、後設資料、定時指令碼和快速例項交付就成了急需解決的的問題。

二、資料庫的標準化

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

  1. 一臺機子上所有例項,都是在統一的目錄下,透過埠進行區分,例如my3306,my3307。然後在my3306下面建立對應的資料目錄、日誌目錄、執行檔案目錄等
  2. 每個例項獨享一個配置檔案,除serverid , bufferpool_size等引數外其他引數保持一致
  3. 線上環境的MySQL軟體目錄和版本保持一致

三、自動化運維之路一期

在一開始的時候,我們需要著手解決目前的最要緊的事情:備份。對於DBA來說,備份重於一切。如果DBA對自己維護的資料庫的備份情況都一無所知,那麼總有一天,你會遭遇資料丟失的災難。因此,我們開始第一期的工作,ZanDB 備份監控系統。 它實現的主要功能是:

  1. 實時檢視備份的情況,當前應備份例項個數,已完成例項數
  2. 顯示每個備份的耗費時長
  3. 檢視過去5天的備份統計資訊,如總個數,大小等

四、自動化運維之路二期

在實現了ZanDB備份監控系統之後,我們著手開始設計ZanDB 的二期設計研發工作。

在設計ZanDB的過程中,我們將主要功能分成了七部分:備份管理,例項管理,主機管理,任務管理,後設資料管理,日誌管理,日常維護。ZanDB架構

1、任務系統

為了實現例項的備份、後設資料、定時指令碼等工作,必須要有一個健壯的任務排程系統。該任務系統支援多種型別的任務:每天的定時任務,每個星期的定時任務,每個月的定時任務,還支援一定間隔的重複性任務。

該任務系統由一個執行任務的agent和下發任務的排程系統完成,任務排程系統中記錄了所有的任務和任務下主機的時間策略。

透過任務系統,我們徹底的去掉了db主機上的crontab 指令碼,修改任務執行時間、策略以及是否需要執行變得輕而易舉。

2、備份管理

在一期的基礎上,我們完善了備份系統。透過和任務系統相結合,可以輕鬆的設定備份的時間以及備份的例項,是否需要備份等,保證了在業務低峰期執行備份操作。

備份操作由agent執行,備份成功失敗透過相應的回撥地址設定狀態。如果一臺主機上存在備份失敗的例項,可以直接在備份系統中檢視其備份報錯日誌,執行重試,省去了頻繁登入DB主機的痛苦。

同時,備份系統每天針對核心資料庫的備份執行校驗操作。如果發現備份校驗失敗,透過告警平臺觸發微信或者簡訊的告警,方便維護人員第一時間知道是否存在備份失效的情況。

3、主機管理

主機的後設資料是資料庫例項的基礎。在進行主機新增的時候,ZanDB 能夠自動的連線Zabbix 獲取主機資訊,例如磁碟大小,磁碟可用空間,記憶體可用空間等。

4、例項管理

為了儘可能的發揮主機的效能,我們在一臺主機上部署了多個例項,因此主機和例項是一對多的關係。

透過例項管理系統,我們可以實現如下功能:

  1. 檢視當前的例項列表,獲取例項當前的資料大小,日誌大小,主從狀態,是否存在慢查,被kill的SQL,例項歷史資訊效能資訊等等。
  2. 新增單個例項,一對例項,針對一個例項/一對主從新增從庫。新增例項的過程是透過rsync 標準的資料庫模板,然後用my.cnf模板渲染生成標準my.cnf配置檔案,執行的具體步驟可以透過流程系統檢視 ,支援失敗重試。
  3. 例項的主從校驗。在MySQL主從複製中,有可能因為主從複製錯誤、主從切換或者軟體的BUG等導致主從資料不一致。為了提早發現資料的不一致,就需要每天都針對核心資料庫,進行主從的一致性校驗,避免產生線上影響。
  4. 例項拆分,用來將之前在同一個例項裡面的多個schema 拆分到不同的例項裡面
  5. 每天將例項的後設資料進行快照,如慢查資料,資料目錄大小等,方便例項的歷史資料分析。

5、日誌管理

資料庫執行最多的就是SQL,最佳化SQL是DBA的職責。面對那麼多的例項,如果沒有一個日誌系統,只能透過登入每臺DB主機去發現慢查將是一件非常痛苦的事情。為了解放DBA的雙手,同時更好的發現和最佳化慢日誌,保證DB的穩定性,ZanDB 日誌系統由此誕生。

首先例項後設資料收集的過程中,會統計慢查和被kill的SQL的資料,然後更新到例項的後設資料中。透過例項後設資料的慢查資訊,獲取昨日的TOP 慢查。

那麼如何去獲取慢查呢?當然要透過偉大的agent去獲取慢查日誌。慢查在每天都會進行rotate,產生一個新的慢日誌檔案。系統要獲取慢查詳情的時候,透過呼叫pt-query-digest,分析慢日誌檔案,將結果快取起來,進行返回。系統下次再獲取慢查的時候,如果發現該日期的慢查已經存在分析後的結果,直接返回。

同時,日誌管理裡面還包含了被kill的SQL的top情況,和慢查是類似的。

6、後設資料管理

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

透過binlog 後設資料管理,實現了所有例項的binlog資訊管理。binlog後設資料記錄了例項的每個binlog起始時間和結束時間,binlog 保留時長,在進行資料恢復的時候可以快速的定位到某個日誌。

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

由於交易等核心庫資料量非常大,分析慢查等相關資訊的時候,需要根據分片鍵找到對應的例項。我們開發了一個分片後設資料查詢功能,只要提供資料庫名、分片id和分片數量,就可以快速的定位到一個例項,大大的方便了DBA,實現了問題的快速定位。

7、日常維護

日常維護主要是透過agent執行,包括了批次執行SQL,批次修改配置等。

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

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

五、展望

整套ZanDB 系統是採用了Python Django + Percona-Toolkit + Agent + 前端相關技術,同時利用了快取Redis 和 MySQL 後端DB,整套系統採用的技術棧較簡單,實現的功能對於目前來說比較實用。後續會加入資料庫效能診斷,自動分析資料庫慢查,獲取關鍵資訊,自動化拆庫等功能。相信隨著自動化的深入,DBA的手動重複操作將越來越少,將有限的時間投入到更有價值的事情上去。

原文來自  

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22664653/viewspace-2145621/,如需轉載,請註明出處,否則將追究法律責任。

相關文章