在網上,baidu一下，你就能得到一堆heartbeat mysql或者pacemaker mysql實作HA（高可用性）的文章。其實你想實作HA(高可用性)與資料完整性的統一并不容易，下面先對一些已存在的HA方案進行一個簡單回顧和評論
- 方案1： 心跳(heartbeat)和複制(replication)
資料庫一個為master,一個為slave，所有對master資料修改會通過replication複制到slave。兩台機器隻有一個通過floating IP對外提供服務。 當master出問題時，slave能檢測到heartbeat失敗，floatingIP 切換到原有的slave。兩資料庫必須同時啟動
優點：
充分利用mysql複制功能
能做到master出問題時自動切換
手動failover能做到0資料丢失
缺點：
自動Failover時可能會有資料丢失，有一部分資料可能沒有複雜到slave
需要額外技術保證heartbeat和replication的暢通。
如果有兩台以上application serve，就有出現splitbrain問題。
改善：
可以使用linux IP bonding等技術保證heartbeat和replication之間鍊路的可靠性。
- 方案2：heartbeat + drbd
與上一方案類似，也采用floating/virtual IP和heartbeat。不同點就是同時隻有一個mysql處于running狀态，另外一台機器在10.10.10.20 failover之前根本就沒有起mysql。兩資料庫不能同時啟動
優點：
利用廉價的裝置替換共享存貯方案，窮人的選擇
能做到master出問題時自動切換
手動failover能做到0資料丢失
缺點：
自動Failover時可能會有資料丢失， 10.10.10.20當機時可能有drbd資料同步到另外一台機器。
需要額外技術保證heartbeat和drbd的暢通。
如果有兩台以上application serve，就有出現splitbrain問題。
備用機需要比第一種更長時間切換。它必須首先mountdrbd分區，然後啟動mysql。
改善：
可以使用linux IP bonding等技術保證heartbeat和drbd之間鍊路的可靠性。
- 方案3：heartbeat + 共享存儲
與方案2高度類似，隻是用NAS或者SAN等替換了廉價的drbd方案。兩資料庫不能同時啟動
優點：
可以做到0資料丢失，也不需要在網絡中複制資料
能做到master出問題時自動切換
缺點：
成本相對較高。
需要額外技術保證heartbeat的暢通。
有可能出現split brain問題。但是可以通過技術手段避免
備用機需要比第一種更長時間切換。它必須首先啟動mysql。
改善：
可以使用linux IP bonding等技術保證heartbeat之間鍊路的可靠性。
注意不要讓共享存貯成為新的單點故障點。
目前我們實作的方案是primary節點定期寫時間戳和機器名到共享存貯。secondary節點隻有在primary在超過某一時間段沒有更新時間戳的情況下才準備failover。如果primary檢測到secondary上的時間戳需要立即停止服務。
- 方案4：mysql 叢集
優點：
記憶體資料庫，本身就有高可用性，請求響應快，适合實時應用
MySQL ClusterManager能實作幫助自動化管理，故障的檢測和恢複，高可用運維
能實作地理備援
缺點：
由于事務送出是記憶體同步，有下電丢資料的風險
需要自己處理地理備援情況下的split brain
改善：
可以額外開發充分利用cluster地理備援特性，比方地理failover
-
總結：
1，如果你是銀行結算系統，任何資料的不一緻都是不可接受的，可以考慮共享存貯，如果你在乎并發實時性，可以考慮mysql cluster。如果你是窮人，可以選擇drbd。
2，不管哪一種方案，都需要自己考慮split brain。
3，不管哪一種方案，我們都可以利用network bonding技術實作網絡層的備援。這将在後面的文章中繼續介紹
4，heartbeat或者pacemaker幾乎是所有HA開源方案的第一選擇
參考： http://www.doc88.com/p-695588579829.html