420
微店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”的方式，中心控製的方式對於規模化精細化數據庫管理衝突。
中心化存在問題：
-
增加實例需要手動錄入；
-
不能獲取響應時間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",
"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分鍾完成；自動化拆庫（部份老的合在一起的還是要拆的）等等。
另外隨著MySQL自動化運維的深入，我們慢慢地發現這將會演變數據庫成私有雲平台。對於如何更好地服務業務，如何診斷業務數據庫等還需要我們去完善。
原文發布時間為：2016-12-27
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-13 08:42:33