在網際網路時代，業務規模常常出現爆發式的增長。快速的例項交付，資料庫優化以及備份管理等任務都對dba產生了更高的要求，單純的憑藉記憶力去管理那幾十套db已經不再適用。那麼如何去批量管理這些例項的備份、元資料、定時指令碼和快速例項交付就成了急需解決的的問題。
在實現mysql的自動化運維的過程中，最痛苦的無非是目錄的不統一，配置檔案的混亂以及db主機的不標準，而這些不標準的環境會讓自動化運維的路途荊棘重重。所以首先我們將相應的db主機以及目錄做了標準化，將以前不符合的標準的主機和例項進行改造。
一台機子上所有例項，都是在統一的目錄下，通過埠進行區分，例如my3306,my3307。然後在my3306下面建立對應的資料目錄、日誌目錄、執行檔案目錄等
每個例項獨享乙個配置檔案，除serverid , bufferpool_size等引數外其他引數保持一致
線上環境的mysql軟體目錄和版本保持一致
在一開始的時候，我們需要著手解決目前的最要緊的事情：備份。對於dba來說，備份重於一切。如果dba對自己維護的資料庫的備份情況都一無所知，那麼總有一天，你會遭遇資料丟失的災難。因此，我們開始第一期的工作，zandb 備份監控系統。 它實現的主要功能是：
實時檢視備份的情況，當前應備份例項個數，已完成例項數
顯示每個備份的耗費時長
檢視過去5天的備份統計資訊，如總個數，大小等
在實現了zandb備份監控系統之後，我們著手開始設計zandb 的二期設計研發工作。
在設計zandb的過程中，我們將主要功能分成了七部分：備份管理，例項管理，主機管理，任務管理，元資料管理，日誌管理，日常維護。
為了實現例項的備份、元資料、定時指令碼等工作，必須要有乙個健壯的任務排程系統。該任務系統支援多種型別的任務：每天的定時任務，每個星期的定時任務，每個月的定時任務，還支援一定間隔的重複性任務。
該任務系統由乙個執行任務的agent和下發任務的排程系統完成，任務排程系統中記錄了所有的任務和任務下主機的時間策略。
通過任務系統，我們徹底的去掉了db主機上的crontab 指令碼，修改任務執行時間、策略以及是否需要執行變得輕而易舉。
在一期的基礎上，我們完善了備份系統。通過和任務系統相結合，可以輕鬆的設定備份的時間以及備份的例項，是否需要備份等，保證了在業務低峰期執行備份操作。
備份操作由agent執行，備份成功失敗通過相應的**位址設定狀態。如果一台主機上存在備份失敗的例項，可以直接在備份系統中檢視其備份報錯日誌，執行重試，省去了頻繁登入db主機的痛苦。
主機的元資料是資料庫例項的基礎。在進行主機新增的時候，zandb 能夠自動的連線zabbix 獲取主機資訊，例如磁碟大小，磁碟可用空間，記憶體可用空間等。
為了盡可能的發揮主機的效能，我們在一台主機上部署了多個例項，因此主機和例項是一對多的關係。
通過例項管理系統，我們可以實現如下功能：
檢視當前的例項列表，獲取例項當前的資料大小，日誌大小，主從狀態，是否存在慢查，被kill的sql，例項歷史資訊效能資訊等等。
新增單個例項，一對例項，針對乙個例項/一對主從新增從庫。新增例項的過程是通過rsync 標準的資料庫模板，然後用my.cnf模板渲染生成標準my.cnf配置檔案，執行的具體步驟可以通過流程系統檢視 ，支援失敗重試。
例項的主從校驗。在mysql主從複製中，有可能因為主從複製錯誤、主從切換或者軟體的bug等導致主從資料不一致。為了提早發現資料的不一致，就需要每天都針對核心資料庫，進行主從的一致性校驗，避免產生線上影響。
例項拆分，用來將之前在同乙個例項裡面的多個schema 拆分到不同的例項裡面
每天將例項的元資料進行快照，如慢查資料，資料目錄大小等，方便例項的歷史資料分析。
資料庫執行最多的就是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型別的修改配置類似，不同的是，修改配置是會同步變更配置檔案，永久生效，同時也修改記憶體，例如調整慢查時間等。
整套zandb 系統是採用了python django + percona-toolkit + agent + 前端相關技術，同時利用了快取redis 和 mysql 後端db，整套系統採用的技術棧較簡單，實現的功能對於目前來說比較實用。後續會加入資料庫效能診斷，自動分析資料庫慢查，獲取關鍵資訊，自動化拆庫等功能。相信隨著自動化的深入，dba的手動重複操作將越來越少，將有限的時間投入到更有價值的事情上去
運維自動化
1，cobbler安裝環境準備 安裝epel epel release 6 8.noarch.rpm x86 64 epel release 6 8.noarch.rpm x86 安裝系列依賴環境 要是區域網用，建議關閉iptables 或是放行25151 80 69埠 和關閉selinux 檢視狀...
自動化運維
考慮的因素 源 打包為映象 發布到映象庫 利用k8s發布到物理機器執行，以服務的形式對外提供服務 目前的做法 0 建立乙個執行遠端命令的框架 1 每個應用建立乙個部署檔案指令碼 a 指定元 位址 c 同步源 到目標主機 d 接受指令碼引數 vername 2 版本號，映象tag fromport 3...
自動化運維 Spug 輕量級自動化運維平台
對於中小型企業而言，進行主機和應用的管理是比較麻煩的，應用部署往往需要直接連線伺服器，再進行手動的環境配置 拉取 應用構建和部署發布等工作，容易出錯，且耗時費力。乙個好的自動化運維平台，往往能大大節省人力物力，提高開發部署效率。spug，正是乙個面向中小型企業設計的輕量級自動化運維平台。spug，是...