前言
網際網路時代，資料庫如何滿足靈活開發、靈活傳遞的要求？傳統靠dba人肉執行的方式，但在面對大量業務需求時，dba手速再快，記憶力再好估計也不能提供好的資料庫服務。在介紹自動化運維之前，我們先來了解下如何使用資料庫。
資料庫的使用方式主要有兩種：
應用混合部署（執行個體）：有新資料庫需求時，很多人都會選擇找個執行個體，建個資料庫和帳号提供給業務。
好處是能快速提供資料庫服務，這種方式在資料庫運維的過程中會出現一些問題：
第一，互相影響，個别應用有問題會影響所有資料庫；
第二， 應用db的性能名額（qps，tps，rt...）不能擷取；
第三，定位問題源困難；
第四，資源使用不合理。
為了解決以上問題，最終會有拆庫的過程，拆過庫的同學都知道，一個拆庫動作需要确認很多東西，所花費的時間是非常多的，過程中容易産生故障。
應用獨享（執行個體）：在虛拟化，微服務深入人心的今天，應用獨享執行個體是資料庫給出的解決辦法。我們做到的是所有應用獨享執行個體（分庫分表的應用如：分成32個庫的應用，業務初期階段會分布在幾個執行個體中，業務确實需要更多資源時再進行自動化拆庫擴容）。這種方式需要大量的執行個體，傳統單機單執行個體的運維體系就需要演變成單機多執行個體的方式。
由此引出會有一系列問題需要解決：
如何快速提供資料庫服務？
如何避免資料庫資源合理配置設定？
資料庫監控怎麼做？
多執行個體資料庫ha怎麼做？
mysql的标準化與自動化
我們實作的mysql自動化運維體系能夠解決規模化的痛點，主要包括執行個體建立、部署、監控、備份、ha切換、遷移、擴容等方面的自動化，所有子產品的主發點是要能“自動化”的方式運作，盡量少的人為參與。
一、标準化
資料庫上了一定規模後，資料庫的各方面都需要标準規範起來，才能接下去做自動化。執行個體上的标準化我們主要做了以下幾點：
1、應用獨享執行個體
2、資料庫Ｍ<==>s結構，備庫不提供業務流量（異地容災除外）
很多人會選擇一主多備，備庫提供讀流量。這種架構引起的故障挺多的，因為備庫一定會存在延時，備庫機器也會挂掉。事實上大部分時候流量都在主庫是沒問題，如果确實主庫壓力真的太大怎麼辦，我們應該及時發現問題并作出應對（方法可以是緩存＋拆庫）。
3、mysql标準化（帶thread_pool 功能mysql）
資料庫版本一緻
“相同”的my.cnf（除個别個性參數如server_id,buffer_pool_size等）
檔案目錄一緻
二、建構mysql自動化運維體系
一套好的大規模運維體系dbmanage，整體思路是讓一切自動化起來，不需要打通機器間的信任關系，避免或減少人為參與。
1、多執行個體建立
一台機器上面開啟多個不同的端口，運作多個mysql服務程序，共用mysql程式，使用不同配置檔案，提供服務。
關鍵點：
資料檔案目錄标準化
建立執行個體（1.初始化一個标準的資料庫，2.建立執行個體通過rsync控制速率，通過修改 " my.cnf " 檔案建立不同執行個體，因為mysql_install_db安裝新執行個體會占用過多io)
2、中繼資料與監控
資料庫監控沒有采用類似“lepus”的方式，中心控制的方式對于規模化精細化資料庫管理沖突。
中心化存在問題：
增加執行個體需要手動錄入；
不能擷取響應時間rt(tcprstat)；
不能擷取主機性能資料等等。
我們采用自研 db_agent 實作執行個體的自動發現，各項中繼資料及性能資料采集，告别人工處理。
每台資料庫伺服器上運作db_agent；自動發現執行個體，自動采集執行個體資料，主機資料，磁盤資料，自動添加監控。db_agent主要實作以下功能。
采集執行個體資訊(資料庫清單，複制資訊，表中繼資料等等)
心跳更新（每秒更新，因為show slave status的延時是不可靠的）
資料庫性能資料( qps, tps......)
資料庫響應時間rt(tcprstat)
實時慢sql
主機性能資料(告别zabbix)
3、備份
資料庫機器部署備份腳本（不區分是否主備機器），告别手動配置。
隻備份備庫（備份前判斷腳色）
多執行個體并發控制（控制速率及時間）
直接寫入hdfs 或server（推薦hdfs存儲）
4、本地執行agent
遠端操作db機器（建立執行個體，恢複資料庫，etc），通過自定義一些消息調起db機器對應腳本進行操作。
5、監控告警
基于db_agent采集資料，性能畫圖及告警。性能資料寫入graphite。
6、mysql高可用
傳統的使用mha做mysql ha架構是比較通用的方案，主要特點：通過health check 監控mysql叢集，應用通過vip通路mysql，vip通過keepalive選主。這裡不展開這種方式和一些改進型（zookeeper +mha）的痛點，主要講下多執行個體下基于zookeeper是怎麼實作mysql自動化高可用。
改造後的ha架構，跟通常架構的差別在于我們去掉了mysql叢集裡的vip，使用vdds替代；完全去掉mha。通過zookeeper分布式，實作ha_console的高可用。
整個流程是：
vdds(微店分布式資料庫) 建立應用配置
ha_agent向zookeeper注冊臨時節點，并實時更新執行個體資訊。
{
"source_db_role": "slave",
"master_instance": "192.168.1.12_3306",
"repl_status": "ok",
"h_time_delay": 0,
"repl_delay": 0,
"last_change_time": "2016-10-15-01:00:45"
}
ha_console根據zookeeper節點資訊構造切換中繼資料（包括延時，切換對象，複制狀态）
"192.168.1.11_3306": "{
"source_db_role": "master",
}"
ha_console監聽alive目錄臨時節點
alive目錄臨時節點消失進行切換（判斷延時及複制狀态，不符合條件不切換），切換vdds和資料庫
切換前記錄切換資訊（slave：master_log_file: mysql-bin.000007，exec_master_log_pos: 57830。主庫恢複後，用來生成日志解析）
場景一：執行個體crash，執行個體所在的伺服器正常運作，ha_agent運作正常。
執行個體crash，ha_agent 正常運作，主動删除zookeeper 臨時節點，ha_console 判斷資料庫角色，是主庫走切換流程。原執行個體起來之後，作為備庫運作。
場景二：執行個體所在的主機crash。（執行個體和ha_agent同時crash）
此時，由于ha_agent和執行個體同時crash，zookeeper到ha_agent間的通訊失敗。zookeeper 等待超過租約的時間，ha_console 判斷資料庫角色，是主庫走切換流程。原執行個體起來之後，作為備庫運作。
場景三：執行個體正常，網絡異常。
網絡異常會發生大量執行個體掉線或部份異常。大量節點異常：ha_console判斷時間範圍内異常執行個體數量，超過閥值不進行切換，同時切換過程：切換腳本會去判斷資料庫狀态，避免誤切。（zookeeper client 連接配接掉線後，盡管執行個體及ha_agent正常運作，節點不能重用必須等待逾時)
特點：完全不需要人工建入，切換中繼資料自動建構，所有執行個體自動注冊，構造完整的切換中繼資料，避免了繁鎖的配置或配置出錯導緻不能切換。
7、dbtask
通過dbtask 替代人工操作。實作了資料庫建立，配置vdds, 資料庫遷移，拆庫擴容，恢複等等。整體思路是分解動作，每個腳本幹一件事，再串起所有腳本。以資料庫遷移為例我們可以分解為各個子任務，串起任務就是一個完整的自動化資料庫遷移任務。
資料庫遷移：
申請可用資源
執行個體建立
恢複備庫a
恢複備庫b
配置資料源(vdds)
切換前檢查
切換
清除vdds配置
關閉老執行個體
資料庫資源申請：
建立庫，mysql帳号
成果及展望
全套自動化運維體系采用：背景由python+shell+go(實時慢sql解析部分)；前端采用laravel+angularjs。 目前單機日常環境運作100+執行個體，agent的資源占用不多；業務申請資料庫資源<1分鐘完成；自動化拆庫（部份老的合在一起的還是要拆的）等等。
另外随着mysql自動化運維的深入，我們慢慢地發現這将會演變資料庫成私有雲平台。對于如何更好地服務業務，如何診斷業務資料庫等還需要我們去完善。
原文釋出時間為：2016-12-27
本文來自雲栖社群合作夥伴dbaplus