轉自:https://tech.youzan.com/youzan-mysql-auto-ops-road/
一、前言
在互聯網時代,業務規模常常出現爆發式的增長。快速的實例交付,數據庫優化以及備份管理等任務都對DBA產生了更高的要求,單純的憑借記憶力去管理那幾十套DB已經不再適用。那么如何去批量管理這些實例的備份、元數據、定時腳本和快速實例交付就成了急需解決的的問題。
二、數據庫的標准化
在實現MySQL的自動化運維的過程中,最痛苦的無非是目錄的不統一,配置文件的混亂以及DB主機的不標准,而這些不標准的環境會讓自動化運維的路途荊棘重重。所以首先我們將相應的DB主機以及目錄做了標准化,將以前不符合的標准的主機和實例進行改造。
- 一台機子上所有實例,都是在統一的目錄下,通過端口進行區分,例如my3306,my3307。然后在my3306下面創建對應的數據目錄、日志目錄、運行文件目錄等
- 每個實例獨享一個配置文件,除serverid , bufferpool_size等參數外其他參數保持一致
- 線上環境的MySQL軟件目錄和版本保持一致
三、自動化運維之路一期
在一開始的時候,我們需要着手解決目前的最要緊的事情:備份。對於DBA來說,備份重於一切。如果DBA對自己維護的數據庫的備份情況都一無所知,那么總有一天,你會遭遇數據丟失的災難。因此,我們開始第一期的工作,ZanDB 備份監控系統。 它實現的主要功能是:
- 實時查看備份的情況,當前應備份實例個數,已完成實例數
- 顯示每個備份的耗費時長
- 查看過去5天的備份統計信息,如總個數,大小等
四、自動化運維之路二期
在實現了ZanDB備份監控系統之后,我們着手開始設計ZanDB 的二期設計研發工作。
在設計ZanDB的過程中,我們將主要功能分成了七部分:備份管理,實例管理,主機管理,任務管理,元數據管理,日志管理,日常維護。
1、任務系統
為了實現實例的備份、元數據、定時腳本等工作,必須要有一個健壯的任務調度系統。該任務系統支持多種類型的任務:每天的定時任務,每個星期的定時任務,每個月的定時任務,還支持一定間隔的重復性任務。
該任務系統由一個執行任務的agent和下發任務的調度系統完成,任務調度系統中記錄了所有的任務和任務下主機的時間策略。
通過任務系統,我們徹底的去掉了db主機上的crontab 腳本,修改任務執行時間、策略以及是否需要執行變得輕而易舉。
2、備份管理
在一期的基礎上,我們完善了備份系統。通過和任務系統相結合,可以輕松的設置備份的時間以及備份的實例,是否需要備份等,保證了在業務低峰期執行備份操作。
備份操作由agent執行,備份成功失敗通過相應的回調地址設置狀態。如果一台主機上存在備份失敗的實例,可以直接在備份系統中查看其備份報錯日志,執行重試,省去了頻繁登錄DB主機的痛苦。
同時,備份系統每天針對核心數據庫的備份執行校驗操作。如果發現備份校驗失敗,通過告警平台觸發微信或者短信的告警,方便維護人員第一時間知道是否存在備份失效的情況。
3、主機管理
主機的元數據是數據庫實例的基礎。在進行主機新增的時候,ZanDB 能夠自動的連接Zabbix 獲取主機信息,例如磁盤大小,磁盤可用空間,內存可用空間等。
4、實例管理
為了盡可能的發揮主機的性能,我們在一台主機上部署了多個實例,因此主機和實例是一對多的關系。
通過實例管理系統,我們可以實現如下功能:
- 查看當前的實例列表,獲取實例當前的數據大小,日志大小,主從狀態,是否存在慢查,被kill的SQL,實例歷史信息性能信息等等。
- 新增單個實例,一對實例,針對一個實例/一對主從添加從庫。新增實例的過程是通過rsync 標准的數據庫模板,然后用my.cnf模板渲染生成標准my.cnf配置文件,執行的具體步驟可以通過流程系統查看 ,支持失敗重試。
- 實例的主從校驗。在MySQL主從復制中,有可能因為主從復制錯誤、主從切換或者軟件的BUG等導致主從數據不一致。為了提早發現數據的不一致,就需要每天都針對核心數據庫,進行主從的一致性校驗,避免產生線上影響。
- 實例拆分,用來將之前在同一個實例里面的多個schema 拆分到不同的實例里面
- 每天將實例的元數據進行快照,如慢查數據,數據目錄大小等,方便實例的歷史數據分析。
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的手動重復操作將越來越少,將有限的時間投入到更有價值的事情上去。
如無特殊說明,本文版權歸 本文作者及有贊技術團隊 所有,采用 署名-非商業性使用 4.0 國際許可協議 進行許可。
轉載請注明:來自有贊技術團隊博客 http://tech.youzan.com/youzan-mysql-auto-ops-road/