方案優勢：
Galera能夠實現MySQL/MariaDB數據庫的主主複製和多主複製等模式，這些複製模式都是同步進行的，同步時間非常短
每一個節點都可以同時寫入和讀取，當某一節點發生故障時，可自動從集羣中自動剔除
HAProxy能提供負載均衡和故障判斷等功能解決服務器系統存在的單點故障
Keepalived能提供客戶端連接數據庫時使用的虛擬IP地址（VIP）
關於HAProxy的負載均衡算法
輪詢方式（roundrobin）：不適合用於backend爲web服務器的情況，因爲session、cookie會話保持會出現輪詢導致的隨機切換，是處理速度最快的算法，但最大服務器數量不能超過4095
原地址方式（source）：適合於backend爲web服務器的情況，能夠實現session、cookie會話保持
最少連接算法（leastconn）：適合於服務器配置相同或者相近的情況，能最大限度的將工作負載平均分配到每一臺服務器上，它適用於session較長的連接，如SQL、LDAP、TSE等，但不適合於session較短的連接，例如它不適合於http連接
權重算法（static-rr），根據服務器的權重（weights）輪流使用每一個服務器，有計劃（根據權重）的去輪詢，此種方式將佔用較少的CPU資源，大約降低1%
除此之外還有可以根據請求的URI和請求的URI參數的uri算法和uri-param算法以及根據HTTP header內容決定是否輪詢的hdr算法，還有rdp-cookie算法可以根據cookie決定請求發往那一臺服務器。
測試結果
當其中的一個節點發生宕機或事故導致數據庫關閉或網絡中斷時，haproxy的狀態能及時的顯示後端節點的連接狀態並將錯誤的節點從服務器資源池中移除，當網絡或宕機恢復時，只有數據庫啓動成功後才能使得haproxy的狀態顯示正常。
目前此方案已經應用於OpenStack雲平臺開發環境，提供active-active高可用服務。
存在或已知問題
採用MySQL/MariaDB+Galera方案的數據庫集羣將僅對Innodb有效，而且不再支持查詢緩存
關於CentOS7 的時間同步問題，時間同步服務已經由ntpd更新爲chrony，可用yum info chrony查看chrony的簡介以及用man查看chrony的用法
關於CentOS7 的日誌服務問題，日誌服務已經由syslog更新(CentOS6開始)爲journald(rsyslogd) ，其配置文件變爲/etc/rsyslog.conf
在<Red Hat Enterprise Linux 7 System Administrator's Guide>手冊中提到
“Log files can also be managed by the journald daemon – a component of systemd.
The journald daemon captures Syslog messages, kernel log messages,
initial RAM disk and early boot messages as well as messages written to standard output
and standard error output of all services, indexes them and makes this available to the user.”
具體參見“Chapter 18, Viewing and Managing Log Files”，以及man rsyslogd.
啓用日誌支持：
#syslog-->Rsyslog-->journald
# enable syslog for haproxy
sed -i 's/SYSLOGD_OPTIONS=""/SYSLOGD_OPTIONS="-r"/g' /etc/sysconfig/rsyslog
cat >/etc/rsyslog.d/haproxy.conf<<eof
# Log haproxy(local2.*) stuff
\$ModLoad imudp
\$UDPServerRun 514
local2.* /var/log/haproxy.log
eof
chown -R --reference=/etc/rsyslog.d/listen.conf /etc/rsyslog.d/haproxy.conf
chcon -R --reference=/etc/rsyslog.d/listen.conf /etc/rsyslog.d/haproxy.conf
systemctl restart rsyslog.service
# enable syslog for keepalived
sed -i 's/KEEPALIVED_OPTIONS="-D"/KEEPALIVED_OPTIONS="-D -S 0"/g' /etc/sysconfig/keepalived
cat >/etc/rsyslog.d/keepalived.conf<<eof
# Log keepalived(local0.*) stuff
\$ModLoad imudp
\$UDPServerRun 514
local0.* /var/log/keepalived.log
eof
chown -R --reference=/etc/rsyslog.d/listen.conf /etc/rsyslog.d/keepalived.conf
chcon -R --reference=/etc/rsyslog.d/listen.conf /etc/rsyslog.d/keepalived.conf
systemctl restart rsyslog.service
tips：
Galera的配置中第一臺服務器的wsrep_cluster_address可以設置成“gcomm://”，而第二個節點的wsrep_cluster_address可以設置成“gcomm://第一個節點的IP地址”，第三個節點的wsrep_cluster_address可以設置成“gcomm://第二個節點的IP地址”，以此類推，但需要注意的是必須第n個節點先於第n+1個節點啓動數據庫，第n+1個數據庫才能啓動成功
Galera的配置中不要將gcomm://寫成dumm://，dumm://僅用於測試用途
Galera的配置中wsrep_provider_options的與ssl相關的文件可以從此選項中移除掉或者將所有的節點都使用一套ssl文件，包括證書和key
HAProxy可以通過option mysql-check user dbuser檢查後端服務器數據庫的運行情況
HAProxy的最大連接數將決定整個集羣的最大連接數，因此HAProxy的maxconn值應該設置成（後端服務器的數量後端服務器所能承受的最大連接數90%）*110%，其中90%和110%表示可承受負載的餘量
keepalived可以採用互爲主備的設計策略，關於互爲主備關係的兩個VIP的用途，猜測是一個VIP提供A服務，另一個VIP提供B服務，這樣“解決”了其中一個節點長期處於備機狀態的情況。
有時爲了減少keepalived中主備之間的搶斷，可以將主備設置成備備，但將其中一個備機設置成非搶斷模式，這樣可以防止出現master宕機恢復後的搶斷情況，減少VIP的切換時間
HAProxy+keepalived的方案也可以用於http類型的傳輸協議，此時針對這單一情況還可以使用nginx+keepalived等負載均衡方案
配置文件請看原文鏈接。
以上出自：原文 http://blog.51cto.com/dgd2010/1603972
補充其他博客信息，以便理解架構模型
模型一
mariadb galera cluster集羣基於wsrep協議可以實現mysql多主複製架構，詳細說明如下：
galera cluster複製：
galera cluster本身是基於wsrep協議工作在底層的文件複製通道而已，只需要指明覆制的文件，它會自動在多個節點之間的檢測文件狀態並完成數據同步。並且galera cluster向上提供API，其他組件只需調用其API，即可完成所需的文件複製功能。
galera cluster向上提供API，mysql只需調用其API即可。所以原生的mysql版本是沒有galera cluster功能的，需要下載附帶galera的版本纔可以，mysql官方也有提供支持galera的版本。
而haproxy是mariadb galera cluster前端的負載均衡組件，可以實現把mysql請求按照指定的調度算法分發給後端的mariadb galera cluster存儲。而keepalived則可以實現haproxy的高可用。
出處：http://blog.51cto.com/changeflyhigh/1886032
模型二
應用服務器對只讀的應用程序連接虛擬IP地址，連接到haproxy，然後通過haproxy將TCP協議轉移到下面的3個數據庫服務器中。Haproxy在此做4層的TCP交換服務。keepalived爲了防止haproxy單點故障。
