微店 MySQL 自動化運維實踐
前言
互聯網時代，數據庫如何滿足敏捷開發，敏捷交付的要求。傳統靠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程序，使用不同配置文件，提供服務。
關鍵點：
-
“相同”的my.cnf（除個別個性參數如server_id,buffer_pool_size等）
-
數據文件目錄標準化
-
創建實例（1.初始化一個標準的數據庫，2.新建實例通過rsync控制速率，通過修改 " my.cnf " 文件新建不同實例，因為mysql_install_db安裝新實例會占用過多IO)
2. 元數據與監控
數據庫監控沒有采用類似“lepus”的方式，中心控制的方式對于規模化精細華數據庫管理沖突。中心化存在問題1：增加實例需要手動錄入；問題2：不能獲取響應時間RT(tcprstat)；問題3：不能獲取主機性能數據等等。我們采用自研 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",
"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監聽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帳號
-
配置數據源(VDDS)
成果及展望
全套自動化運維體系采用：后臺由python+shell+go(實時慢sql解析部分)；前端采用laravel+angularjs。 目前單機日常環境運行100+實例，agent的資源占用不多；業務申請數據庫資源<1分鐘完成；自動化拆庫（部份老的合在一起的還是要拆的:sob:）等等。另外隨著MySQL自動化運維的深入，慢慢的發現這將會演變數據庫成私有云平臺。對于如何更好的服務業務，如何診斷業務數據庫等等都需要我們去完善。
參考資料
python socket通信：
https://github.com/chris-piekarski/python-json-socket
python hdfs
https://pypi.python.org/pypi/hdfs/
響應時間 (rt):
https://github.com/Lowercases/tcprstat
python zookeeper:
https://github.com/python-zk/kazoo
go tidb 解析 sql 中的表（用來合并分表）
https://github.com/pingcap/tidb
來自：http://mp.weixin.qq.com/s/ccD_j5QxPC0kyzRvU3KOJw