这里分享一篇mysql集群部署方式，采用的是MariaDB多主方式（Multi-Master），适合用在高可用环境中。一般3个节点之上有一个高可用VIP（HAProxy + Keepalived），对开发者而言，只有一个数据库IP。3个节点挂掉一个，不会影响使用，运维及时恢复即可。那么我们先看看集群需要的菜谱：

三台服务器ubuntu14.04

192.168.3.1

192.168.3.2

192.168.3.3

MariaDB（10.1，因为10.1之后自带Gelera，无需单独安装）

Gelera（10.1之前版本需要单独安装）

rsync （集群互相学习使用的默认同步方式）

1. 软件安装

sudo apt-get install software-properties-common

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db

sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] trusty main'

sudo apt-get update

sudo apt-get install rsync mariadb-server

安装软件后，首先把mysql服务停掉，完成配置后在启动。

2. 配置项

这里集群最少3台服务器，防止网络波动出现脑裂问题。3个服务器配置是相同的，如下：

vim /etc/mysql/my.cnf

# * Galera-related settings

#

[galera]

# Mandatory settings

wsrep_on=ON

wsrep_provider=/usr/lib/libgalera_smm.so

wsrep_cluster_address="gcomm://192.168.3.1,192.168.3.2,192.168.3.3"

binlog_format=row

default_storage_engine=InnoDB

innodb_autoinc_lock_mode=2

wsrep_cluster_name="MariaDB_Cluster"

#

# Allow server to accept connections on all interfaces.

#

bind-address=0.0.0.0

#

# Optional setting

#wsrep_slave_threads=1

#innodb_flush_log_at_trx_commit=0

3. 启动集群

这里顺序比较重要，在其中一台服务器上执行语句：

service mysql start --wsrep-new-cluster

该语句是利用此节点创建一个集群节点，作为初始节点。其他两台服务器使用正常的启动就可以了，不需要使用其他参数：如下

service mysql start

如果遇到问题：ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)

因为集群中使用debian-sys-maint用户登录，而用户的密码是配置在debian.cnf中的，所有解决办法：

找到debian.cnf中的password，并修改成例如newxxx

使用语句重新设置debian-sys-maint的密码。语句见下面

重新启动集群。

set password for 'debian-sys-maint'@'localhost'=password('newxxx');

4. 验证集群

分别登录3个节点

mysql -uxxx -pxxxx

使用语句查看集群状态，wsrep_cluster_size = 3，其他参数注意观察，对后续运维很重要。

show status like 'wsrep_*';

last_comitted故障恢复使用

箭头参数，运维注意

5.集群说明（有看头）

虽然多个数据库节点实现了高可用，但这里带来一个架构问题，数据一致性问题，在并发较高，对事务要求比较严格的应用中会出现问题。

业务场景：

会员A在平台预定了一个产品，在9点整自动下单，此时会从会员中扣除费用。如果在扣费的过程中，A也充值了，很可能就会出现问题。

最根本的原因：事务没有锁住会员账户。这里牵扯到了两个事务，分别是扣费事务和充值事务。而这两个事务很可能不在同一个数据库节点上，例如扣费事务在01节点锁住账户，并更新余额。02节点没来得及学习，充值事务就来了，02节点也锁住了账户，完成了更新，并释放锁后学习了01的更新，导致02节点丢失了充值事务的操作。

有频繁更新且对事务要求比较严格的时候，就不要考虑使用这种方式，这种方式适合写多、并发更新少的场景。

Q：有办法避免事务不一致的问题吗？

A：改为读写分离的代码实现，完美解决上述问题。选择其中两个节点做VIP，另外一个做Master。注意使用sharding-jdbc，引入maven后数据源配置如下。

代码示例：

用图片看代码更爽

注意：同一线程且同一数据库连接内，如有写入操作，以后的读操作均从主库读取，用于保证数据一致性。所有使用这种方式，能满足绝大多数业务场景了。

感谢您的阅读，不足之处，还望指正。有疑问，可留言。