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操作，節省數據庫故障切換的時間，爲京東的數據庫保駕護航。
