keepalived高可用之間是通過vrrp通訊的；vrrp通過競選機制確定主備，主的優先順序高於備，因此在工作時主優先獲得資源，備節點處於等待狀態，當備節點無法接收到主節點的心跳資訊時，備節點就回接管主節點的所有資源，頂替主節點對外服務。vrrp:虛擬路由冗餘協議，主要是解決靜態路由的單點故障問題；
vrrp是通過一種競選協議機制將路由交給某台vrrp路由器的；
vrrp是用ip多播的方式實現高可用對之間的通訊
主節點發包，備節點接包，當備節點接收不到主節點傳送的資料報時，就啟動接管程式接管主節點的資源。備節點有多個，也是通過競選機制接管主節點的資源
vrrp使用了加密協議加密數，但是keepalived官方依然使用的是明文方式進行認證配置的；
1)、heartbeat 專案是 linux-ha 工程的乙個組成部分，它實現了乙個高可用集群系統。心跳服務和集群通訊是高可用集群的兩個關鍵元件; 通過修改heartbeat的配置檔案，可以指定一台heartbeat伺服器作為主伺服器，另一台自動成為熱備伺服器。在熱備伺服器上面配置heartbeat守護程式來監聽來自主伺服器的心跳資訊。如果在規定時間內，無法監聽到心跳資訊，那麼就啟動故障轉移，取得主伺服器上的相關資源的所有權，接替主伺服器繼續不間斷的提供服務，從而達到資源以及服務高可用的目的。heartbeat還支援主主模式，及兩台伺服器互為主備。一般故障切換時間在5~20s之間。
另外：和keepalived的服務一樣，heartbeat高可用是伺服器級別的，不是服務級別的。
伺服器宕機
heartbeat軟體故障
心跳連線線故障）
服務故障不會導致切換，可以通過服務宕機把heartbeat服務停掉。
2）、 心跳連線：
至少需要兩台主機才可以實現高可用服務。
兩台heartbeat服務之間通訊:
穿行電纜，所謂的串列埠（首先，缺點是距離不能太遠）
一根乙太網電纜兩網絡卡直連（常用方式）
乙太網電纜，通過交換機等網路裝置連線。（交換機可能出現問題等）
1）keepalived使用更簡單：從安裝、配置、使用、維護等角度上對比，keepalived都比heartbeat要簡單得多，尤其是heartbeat 2.1.4後拆分成3個子專案，安裝、配置、使用都比較複雜，尤其是出問題的時候，都不知道具體是哪個子系統出問題了；而keepalived只有1個安裝檔案、1個配置檔案，配置檔案也簡單很多；2）heartbeat功能更強大：heartbeat雖然複雜，但功能更強大，配套工具更全，適合做大型集群管理，而keepalived主要用於集群倒換，基本沒有管理功能；
3）協議不同：keepalived使用vrrp協議進行通訊和選舉，heartbeat使用心跳進行通訊和選舉；heartbeat除了走網路外，還可以通過串列埠通訊，貌似更可靠；
4）使用方式基本類似：如果要基於兩者設計高可用方案，最終都要根據業務需要寫自定義的指令碼，keepalived的指令碼沒有任何約束，隨便怎麼寫都可以；heartbeat的指令碼有約束，即要支援service start/stop/restart這種方式，而且heartbeart提供了很多預設指令碼，簡單的繫結ip，啟動apache等操作都已經有了；
web的高可用採用keepalived,如果資料庫之間做高可用，也可以使用keepalived，但是推薦採用heartbeat；
Oracle和MySQL的高可用方案對比（一）
關於oracle和mysql的高可用方案，其實一直想要總結了，就會分為幾個系列來簡單說說。通過這樣的對比，會對兩種資料庫架構設計上的細節差異有乙個基本的認識。oracle有一套很成熟的解決方案。用我在oow上的ppt來看，是maa的方案,今年是這個方案的16周年了。而mysql因為開源的特點，社群裡...
Azure 高可用方案
可用性集是 vm 的邏輯分組，可讓 azure 了解應用程式的構建方式，以便提供冗餘和可用性。建議在可用性集內建立兩個或多個 vm，提供高度可用的應用程式，並滿足 99.95 azure sla 的要求。可用性集由可防止硬體故障以及允許安全應用更新的兩個額外分組構成 容錯域 fd 和更新域 ud 容...
PostgreSQL 內建高可用方案
注意 以下內容翻譯與postgresql 10.3 高可用篇 是sdf 修改過的乙個檔案系統複製的版本 若乙個電腦的檔案系統發生變化，則這些改變會被映象複製到其他所有的檔案系統中。唯一的約束是 映象複製的時候必須確保 從庫和要複製的檔案系統已經保持一致，尤其是 往從庫 寫操作的時候必須是和往主庫寫是...