Haproxy+Keepalived+MySQL/MariaDB+Galera构建高可用数据库集群
方案优势：
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
在
“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</etc/rsyslog.d/keepalived.conf< 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单点故障。
出处：http://blog.itpub.net/25704976/viewspace-1319781/