mysql高可用方案中mha絕地是乙個相當成熟的實現。對於資料的切換，其實mgr也能很好的完成，也就是說，資料層面的角色切換已經刻意很平滑的做好了，但是對於訪問ip的處理，還是有很大的空間，mha提供了很多可選的空間來支援。
常見的組合方式有：
mha+vip
mha+keepalive
mha+zookeeper
當然mha+vip是一種很成熟和經典的方案了。
一般來說都有以下類似的架構方式，假設架構模式為一主兩從。對於應用訪問來說，提供的ip資訊就依據繫結的vip位址為準。vip可以根據節點的資料狀態在不同節點間漂移，達到無縫切換的高可用。
mha manager是乙個核心的排程器，有了它可以排程多套環境，當然mha manager自身也有單點，所以會考慮兩套mha manager節點來做冗餘，實際上是做交叉互備，比如有100套環境，兩個mha manager節點，那就每個分50個節點，如果manager節點出現故障，可以很順利的交接給manager2來接管。
對於應用來說，就是統一通過vip的方式來訪問。如果是在這個基礎上考慮中介軟體的方案，則資料訪問的策略會更加複雜一些。
對於這樣的乙個基本方案，如果從多個維度來下鑽會發現有很多需要注意的地方，所以問題無處不在，可喜的是在mha中幾乎都考慮到了。如果說得簡單點，主要有下面的幾個場景需要考慮：
資料庫主庫宕機
資料庫從庫宕機
重啟資料庫主庫
重啟資料庫從庫
從庫應用延遲
主從網路延遲
主庫伺服器宕機
從庫伺服器宕機
一主多從切換優先順序
網路抖動的切換
手工主從切換
主節點ip調整
從節點ip調整
新增從節點
剔除從節點
網路抖動的預防
半同步外掛程式對於mha的影響
自定義mha指令碼
所以上面的方案多多少少都需要考慮，如果用下面的圖來表示，就會大體有如下的一些紅色警告。所以各個層面都會有可能存在問題和異常，如何盡可能不影響業務，保持業務科持續訪問是重中之重。
舉乙個比較糾結的問題，如果mha manager節點到資料庫主庫的網路發生抖動，導致短時間不可訪問，我們是希望這個過程是不會做災難切換的，但是如果時間過長了，有2分鐘或者3分鐘都不可訪問，這個時候是切還是不切呢。這個時候資訊還是相對較少的，如果我們加入應用伺服器這個角色，如果應用伺服器是可訪問的，那麼就不切，如果應用訪問受到影響，那還是切吧。而且根據我們的測試，在mha 0.56和0.57裡面還是有一些差別。測試了多套環境，測試了多個特性，結合起來才會發現對於mha的考慮會更加全面，而換句話說，了解了原委，才能更好的掌握mha，也才能看到更多的問題，來嘗試定製它，使得它更加滿足於當前的業務需求。
mysql系列 mha高可用
一 切換流程 1 mha通過主探測服務和第二檢測指令碼判斷主庫服務不可用 2 獲取所有存活從庫最新讀取的mysql binlog位點,進行對比,或許最新的位點資訊 3 如果主庫伺服器還能連線,根據位點資訊拷貝位點之後的差異binlog 4 選擇新主 1 如果沒有新主配置,則選擇最新位點資訊的從庫 2...
mysql高可用集群 MHA架構
或者 新增乙個yum源 wget ease 5 4.noarch.rpm 系統核心 mysql版本 記憶體centos release 5.8 linux 2.6.18 308.el5xen mysql 5.5.352g 2.架構 伺服器列表 ip機器名 角色192.168.2.7 haproxy0...
MHA部署實現高可用（1）
環境準備 三颱 centos 7 機器 可聯網 永久修改機器名稱，斷開三颱機器xshell重連實現名稱的修改 一 以下需要在三颱機器上操作 1 三颱機器分別操作時間同步 echo 5 usr sbin netpdate ntp1.aliyun.com dev null 2 1 var spool c...