京東MySQL數據庫主從切換自動化

1. 產生背景

隨着京東業務的高速增加，數據的重要性對於京東來講重要程度不說自明，在信息時代，數據有着比人們更大的力量，數據庫的價值可見一斑，數據庫的存在爲人們提供了更快的查詢，那麼爲了更好地作到數據庫的高可用，保證持續提供服務，簡化DBA操做，節省數據庫故障切換的時間，故開發此數據庫主從切換自動化系統。

2. 實現原理

此係統基於MHA作數據庫切換，結合京東數據庫切換的特色，定製本身的切換系統。MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司Yoshinori Matsunobu開發，是一套優秀的做爲MySQL高可用性環境下故障切換和主從提高的高可用軟件。在MySQL故障切換過程當中，MHA能作到在0~30秒以內自動完成數據庫的故障切換操做，而且在進行故障切換的過程當中，MHA能在最大程度上保證數據的一致性，同時最大化挽回故障發生後的數據，結合zabbix監控報警，以達到真正意義上的高可用。三重檢測，保證切換無誤：zabbix檢測，任務建立時檢測，MHA檢測。

3. 實現功能

此係統實現了死切（從庫故障切換及回切，主庫故障切換），活切（主庫活切及主庫回切），作到自動化、自助化、可視化切換。

4. 具體實現

4.1. 死切（故障切換）

當Zabbix自動監控系統檢測到數據庫故障時，會自動調故障切換程序,而後判斷是主庫故障，仍是從庫故障，分狀況處理，全部的故障信息均可在DBS系統上查看

4.1.1 主庫故障：

先在DBS系統上建立切換任務，另外DBA也可在故障切換頁面批量添加故障主庫IP，建立切換任務。而後相應DBA執行切換按鈕，則會判斷各類狀況

4.1.1.1切換重要步驟及原則

l 探活，探活檢測機制由select方式改成insert方式，這樣能夠包含實例夯住和硬盤只讀的狀況，若是沒有存活的從庫，則放棄本次操做並郵件和短信通知DBA手動處理。

l 選擇新主庫，先本地（先物理機後DOCKER,先鏈接數少，後QPS負載低），後異地（先物理機後DOCKER,先鏈接數少，後QPS負載低）原則選擇目標實例

l 調MHA接口進行故障切換故障系統信息變動

a．MHA會優先使用上一步選出的從庫作爲新主庫，不然會使用最新數據的從庫提高爲新主庫，而後將全部其餘的從庫從新指向新主庫。以後會調用域名切換接口，將原來故障主庫下的域名，所有指向到新的主庫IP上。若是MHA切換失敗或MHA有告警信息，或者有域名未切換成功，都會使用郵件和短信通知DBA人工處理。

b．當MHA故障切換結束後，系統會將新主庫的mysql.cnf配置文件中的read_only=1刪除，並在新主庫上執行reset salve all或stop slave指令。

c．調用zabbix主機更名接口，修改故障主庫及新主庫在zabbix監控系統中的名稱。

d. 因爲域名切換後非實時生效，存在時延，所以系統會對域名生效進行檢查，若是2分鐘內未生效，則會進行提示，須要DBA進行人工確認。

e. 最後，在資產庫中更新集羣信息，修改主從關係並進行數據庫狀態變動，更新故障信息表。同時，發送郵件和短信通知DBA故障切換完成。

f.活切能夠支持多集羣同時切換。

4.1.1.2 舉例

例若有一主四從的集羣，主庫 10.66.66.66:3366故障，須要切換，以下：

1.Zabbix自動建立任務，而後DBA執行切換

2.選目標實例

假如例子中的4個從都是存活的，那麼在此處會比較根據先本地，選出10.66.66.68:3366，10.66.66.69:3366，而後查鏈接數，都相同，則去查QPS,

而後比較QPS，選出QPS負載低的10.66.66.69:3366做爲目標實例。

3.切換完成結果

4.切換的詳細信息

4.1.2從庫故障（系統自動完成）：

4.1.2.1 切換原則

判斷是否宕機實例沒有域名，宕機實例設置爲手動切換，宕機實例所在集羣無其餘正常運行實例，這些狀況下會給相應的DBA發郵件及短信報警，須要DBA手動處理；

其餘狀況故障系統會自動處理，根據先本地（鏈接數少，QPS負載低），後異地（鏈接數少，QPS負載低）原則選擇目標實例，進行域名切換，切換成功或失敗都會發郵件及短信告知相應的DBA；

切換成功的從庫，相應的DBA能夠回切該實例。

4.1.2.2 舉例

例若有一主四從的集羣，從庫 10.88.88.89:3366故障，須要切換，以下：

zabbix會自動建立任務，並根據先本地後異地，而後查鏈接數，QPS原則，肯定目標實例爲10.88.88.88:3366，而後自動切換，DBA會在切換任務列表查看切換結果，鼠標懸停執行狀態會顯示切換的具體信息

切換成功的任務會顯示回切按鈕，能夠執行回切

DBA執行回切，系統會建立回切任務，並能夠查看回切的具體信息

4.2活切(通常運維停機切換)

4.2.1 批量建立任務：

輸入項目裏的任一IP，就能夠查出該項目下的全部可用集羣，而後勾選想要切換的集羣，提交批量建立任務。

建立任務時可選擇目標實例是本地，仍是異地。而後先對目標實例探活，再根據先物理機後DOCKER，先查鏈接數少，後查QPS負載低的原則推薦實例。若是有異常會提示。

另外可選擇切換後新主庫是否爲read only

4.2.2任務切換

點擊切換，會批量切換本次任務，並能夠進入子任務查看具體切換的每一個步驟，及MHA執行的每一個步驟，切換完成，會等待2分鐘去校驗域名是否真實切換。

切換後會有先後架構的對比。

能夠kill舊主庫的全部應用連接。

4.2.3 舉例

有個Mysql_test項目下有2個集羣，以下

集羣1

集羣2

1. 批量建立任務

選擇原則根據先本地後異地，先物理機後Docker,先鏈接數後QPS原則，

10.66.66.66:3366選擇目標主庫爲：10.88.88.89:3366

10.66.55.55:3366選擇目標主庫爲：10.88.99.91:3366

2. 批量執行切換

切換子任務詳細信息，可查看到每一個子任務的切換結果及執行步驟，先後架構

5. 總結

該系統不論是死切，仍是活切，都已服務化，接口化，都只需最多2步（建立任務，執行切換）就可完成切換，也能夠徹底自動化切換（須要業務方贊成，由於有些業務數據庫故障後須要業務方確認切換），也能夠把活切作成流程化交給業務方自助切換。目前該系統已經運行良好，極大的節省了DBA時間，更好地作到數據庫的高可用，保證持續提供服務，簡化DBA操做，節省數據庫故障切換的時間，爲京東的數據庫保駕護航。