避免 MySQL Fabric 成為單點故障
我設法安裝和配置管理多個 MySQL 伺服器節點的 MySQL Fabric。它工作得很好，因為我通過直接連接到主節點並使用數據（插入、刪除）對其進行了測試。從節點變得與主節點相同。
現在，結構伺服器應該管理一切。因此，應用程序應該連接到 Fabric 而不是主節點。這樣，當 Master 失敗時，Fabric 會提名一個新的 Slave。
Q1：如何避免 Fabric 伺服器本身成為單點故障？
Q2：誰有實現 Fabric 的經驗？我打算做的是最佳實踐嗎？
問候，
MySQL Fabric 節點本身目前不是冗餘的，但如MySQL Fabric FAQ中所述：
目前只有一個 MySQL Fabric 節點實例。如果該程序失敗，則可以在該機器或另一台機器上重新啟動它，並從現有狀態儲存（MySQL 數據庫）或狀態儲存的複制副本中讀取狀態和路由資訊。
當 MySQL Fabric 節點不可用時，Fabric-aware 連接器繼續根據路由數據的記憶體副本將查詢和事務路由到正確的 MySQL 伺服器。但是，如果主節點發生故障，在 MySQL Fabric 節點恢復服務之前不會發生自動故障轉移，因此盡快恢復程序非常重要。
在最佳實踐方面，這篇MySQL Fabric 部落格文章提供了使用 MySQL Fabric 的端到端工作範例，然後MySQL Fabric 白皮書添加了更多概述和上下文資訊。
最後，您可以觀看 MySQL Fabric 網路研討會重播並閱讀問答記錄——那裡有一些很好的技術問題 + 回复。
如果您正在尋找有關該主題的更多討論，那麼還有一個專門的 MySQL Fabric、Sharding、HA 和 Utilities 論壇。
我知道這有點老了，但我正在考慮使用 MySQL Fabric 設置一些集群並遇到了同樣的問題。
我找到的最佳答案是使用 Pacemaker 和 Corosync。在做出決定之後——幸運的是——我發現 MySQL Utilities Manual 已經有一節介紹瞭如何正確設置。
http://dev.mysql.com/doc/mysql-utilities/1.5/en/fabric-pacemaker.html