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

標籤：自增   擷取參數   共用   ota   sch   時間   都對   好的   團隊   

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

 

一、前言

在互連網時代，業務規模常常出現爆髮式的增長。快速的執行個體交付，資料庫最佳化以及備份管理等任務都對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的過程中，我們將主要功能分成了七部分：備份管理，執行個體管理，主機管理，任務管理，中繼資料管理，日誌管理，日常維護。

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的手動重複操作將越來越少，將有限的時間投入到更有價值的事情上去。

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

 

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