京東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切換重要步驟及原則
- 探活，探活檢測機制由select方式改為insert方式，這樣可以包含實例夯住和硬盤只讀的情況，如果沒有存活的從庫，則放棄本次操作并郵件和短信通知DBA手動處理。
- 選擇新主庫，先本地(先物理機后DOCKER,先連接數少，后QPS負載低)，后異地(先物理機后DOCKER,先連接數少，后QPS負載低)原則選擇目標實例
- 調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操作，節省數據庫故障切換的時間，為京東的數據庫保駕護航。
【本文為51CTO專欄作者“王偉”的原創稿件，轉載請注明出處】
