MySQL高可用集羣的VIP切換

1、目的
實如今mysql高可用集羣的VIP切換,不涉及數據補償

2、基礎環境
python3.0+

3、具體三大部分
一、啓動條件檢測

• 檢測集羣是否down機 方式 select 1
• 檢測主庫是否有VIP綁定 方式是 採用vip進行鏈接
• 檢測從庫是否正常複製和延遲
• 檢測從庫是否開啓binlog中繼日誌寫入
• 檢測集羣是否已經開啓了加強半同步方式
• 檢測集羣是否開啓了GTID複製

二、高可用切換流程

• 主庫down機 若是失敗則進行嘗試三次進行斷定
• 摘掉原主VIP,若是能進行SSH登陸的話
• 從slave節點中選擇新主 判斷方式
• 打開new master節點讀寫功能
• new master上綁定VIP
• 在日誌中生成change語句
• 發送報警郵件

三、新主斷定條件

• 選擇集羣從庫加入選舉組,條件是sql_thread 狀態爲YES
• 根據集羣的成員對比 binlog(name and postion) 進行排序,選擇頭部成員
• 對新主進行進一步斷定,斷定條件爲second_master_behind
• 若是爲0,確保sql_thread已應用徹底部relay-log
• 第三步判斷成功,則針對新主採起如下操做：

set global read_only= off 關閉讀寫
ifconfig vip 綁定VIP

4、相關注意點
一、雲環境和多實例環境並不適合VIP環境,因此此文章不適用,不過大致原理相同
二、數據補償依賴加強半同步複製,這是必須的
三、在綁定VIP以前須要arpping VIP,防止出現腦裂問題
四、採用一個集羣啓動一個進程方式,防止出現問題互相影響,固然若是你的python能力很高,能夠隨意改造
五、監控好你的從庫健康狀況,防止高可用切換的時候無健康從庫可用

5、關於應用場景狀況
一、對於集羣都出現延時的狀況比較少見
二、一旦發生這種狀況而又致使切換
重要場景 會堅持relay-log應用完纔會進行切換,業務響應排後
非重要場景 不考慮relay-log應用狀況進行直接

6、總結
本文章只是提供一個思路,若有意見能夠聯繫本人進行修訂

7、切換日誌圖示

---

本文選自知數堂學員-鄧志航的文章；
鄧志航，MySQL DBA,天生的MySQL愛好者,熱衷於爲他人解決問題,善於總結和分享。
對數據平臺構建和排查疑難問題有很是濃厚的興趣

---

公衆號：知數堂，更多MySQL乾貨知識，關注公衆號獲取。

原文連接：https://zhishutang.com/Fte

推薦閱讀：https://zhishutang.com/xdI