MariaDB galera Cluster 介绍
galera Cluster是由第三方公司Codership所研发的一套免费开源的集群高可用方案，实现了数据零丢失，官网地址为http://galeracluster.com/。其在MysqLInnoDB存储引擎基础上打了wrep(虚拟全同步复制)，Percona/MariaDB已捆绑在各自的发行版本中。
MariaDB galera Cluster是MariaDB同步多主机集群。它仅支持XTradB/InnoDB存储引擎（虽然有对MyISAM实验支持，具体看wsrep_replicate_myisam系统变量）。
l 同步复制
l 真正的multi-master，即所有节点可以同时读写数据库
l 新节点加入数据自动复制
l 真正的并行复制，行级
优势：
l 因为是多主，所以不存在Slavelag(延迟)
l 不存在丢失事务的情况
l 同时具有读和写的扩展能力
l 更小的客户端延迟
l 节点间数据是同步的，而Master/Slave模式是异步的，不同slave上的binlog可能是不同的
缺点：
l 加入新节点时开销大，需要复制完整的数据
l 不能有效地解决写扩展的问题，所有的写操作都发生在所有的节点
l 有多少个节点，就有多少份重复的数据
l 由于事务提交需要跨节点通信，即涉及分布式事务操作，因此写入会比主从复制慢很多，节点越多，写入越慢，死锁和回滚也会更加频繁
l 对网络要求比较高，如果网络出现波动不稳定，则可能会造成两个节点失联，galera Cluster集群会发生脑裂，服务将不可用
还有一些地方存在局限：
l 仅支持InnoDB/XTradB存储引擎，任何写入其他引擎的表，包括MysqL.*表都不会被复制。但是DDL语句可以复制，但是insert into MysqL.user(MyISAM存储引擎)之类的插入数据不会被复制
l Delete操作不支持没有主键的表，因为没有主键的表在不同的节点上的顺序不同，如果执行select … limit …将出现不同的结果集
l LOCK/UNLOCK TABLES/FLUSH TABLES WITH READ LOCKS不支持单表所锁，以及锁函数GET_LOCK()、RELEASE_LOCK()，但FLUSH TABLES WITH READ LOCK支持全局表锁
l General Query Log日志不能保存在表中，如果开始查询日志，则只能保存到文件中
l 不能有大事务写入，不能操作wsrep_max_ws_rows=131072(行)，且写入集不能超过wsrep_max_ws_size=1073741824(1GB)，否则客户端直接报错
l 由于集群是乐观锁并发控制，因此，在commit阶段会有事务冲突发生。如果两个事务在集群中的不同节点上对同一行写入并提交，则失败的节点将回滚，客户端返回死锁报错
l XA分布式事务不支持Codership galera Cluster，在提交时可能会回滚
l 整个集群的写入吞吐量取决于最弱的节点限制，集群要使用同一的配置
技术：
当客户端发出一个commit的指令，在事务被提交之前，所有对数据库的更改都会被write-set收集起来，并且将write-set记录的内容发送给其他节点。
write-set将在每个节点上使用搜索到的主键进行确认性认证测试，测试结果决定着节点是否应用write-set更改数据。如果认证测试失败，节点将丢弃 write-set ；如果认证测试成功，则事务提交，工作原理如下图：
关于新节点的加入，流程如下：
新加入的节点叫做Joiner，给Joiner提供复制的节点叫Donor。在该过程中首先会检查本地grastate.dat文件的seqno事务号是否在远端donor节点galera.cache文件里，如果存在，那么进行Incremental State Transfer(IST)增量同步复制，将剩余的事务发送过去；如果不存在那么进行State Snapshot Transfer(sst)全量同步复制。sst有三种全量拷贝方式：MysqLdump、rsync和xtrabackup。sst的方法可以通过wsrep_sst_method这个参数来设置。
备注：
sst是指从donor到joiner的数据全量拷贝，它通常使用在一个新的节点加入时，为了与集群同步，新的节点不得不去一个已经在集群中的节点上拷贝数据，在PXC(Percona XTradb Cluster)中，有三种sst的方法，MysqLdump，rsync，Xtrabackup。
建议使用XtraBackup，另外对XtraBackup补充说明：
在XtraBackup 2.1.x版本里，使用innobackupex备份时，备份流程如下：
1.备份InnoDB表数据
2.执行全局表读锁FLUSH TABLES WITH READ LOCKS
3.拷贝.frm和MyISAM表数据
5.完成redo log事务日志的后台复制
6.解锁UNLOCK TABLES
由上面可以看出如果备份好几张MyISAM存储的大表时，将会进行锁表。
环境信息
MariaDB Server：10.1.21-MariaDB
CentOS：CentOS Linux release7.2.1511 (Core)
MariaDB galera Cluster 三个集群节点主机名和IP地址信息：
192.168.1.104 mariadb-a03
192.168.1.105 mariadb-a04
192.168.1.106 mariadb-a05
环境准备
1.配置hosts文件
# cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 192.168.1.104 mariadb-a03 192.168.1.105 mariadb-a04 192.168.1.106 mariadb-a05
2./etc/security/limits.conf
* soft nofile 65536 * hard nofile 65536
3./etc/sysctl.conf
fs.file-max=655350 net.ipv4.ip_local_port_range = 1025 65000 net.ipv4.tcp_tw_recycle = 1
最后执行：
# sysctl -p
4.安装Percona XtraBackup热备份工具
下载地址：
解压缩：
# tar -zxvf percona-xtrabackup-2.4.6-Linux-x86_64.tar.gz
拷贝脚本到指定位置：
# cd percona-xtrabackup-2.4.6-Linux-x86_64/bin/ # cp -a * /usr/bin/
安装依赖的一些包，比如lsof，socat，openssl，tar等
创建XtraBackup备份时用的用户名和密码：
MariaDB [(none)]> grant all on *.* to 'galera'@'localhost' identified by '123456';
部署MariaDB
从MariaDB 10.1版本开始，galera Cluster就已经包含在MariaDB包里面了，不需要单独部署MariaDB-galera-server 和galera 包。
这里演示使用YUM方式部署MariaDB galera Cluster。
步骤一：配置Yum源（192.168.1.104,192.168.1.105,192.168.1.106）
# touch /etc/yum.repos.d/MariaDB-IDC.repo 添加如下内容： [mariadb] name = MariaDB baseurl =http://yum.mariadb.org/10.1/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1
由于我们的环境无法访问外网，单独部署一个MariaDB的Yum源：
# cat /etc/yum.repos.d/MariaDB-IDC.repo [MariaDB-10.1-IDC] name=MariaDB-10.1-IDC baseurl=http://192.168.1.100/repo/yum.mariadb.org/10.1/centos7-amd64 gpgcheck=0 enabled=1
步骤二：安装MariaDB（192.168.1.104,192.168.1.106）
# yum install MariaDB-server MariaDB-clientgalera -y
配置 MariaDB galera Cluster
下面我们开始配置MariaDB galera Cluster，分别修改MariaDB galera集群的每个节点上的/etc/my.cnf.d/server.cnf文件，具体每个节点的内容如下：
1.192.168.1.104节点的/etc/my.cnf.d/server.cnf文件内容：
[root@mariadb-a03 ~]# cat /etc/my.cnf.d/server.cnf | grep -v "#" | grep -v "^$" [server] [MysqLd] server_id=128 datadir=/app/galera user=MysqL skip-external-locking skip-name-resolve character-set-server=utf8 [galera] wsrep_causal_reads=ON #节点应用完事务才返回查询请求 wsrep_provider_options="gcache.size=4G"#同步复制缓冲池 wsrep_certify_nonPK=ON #为没有显式申明主键的表生成一个用于certificationtest的主键，默认为ON #log-bin=/app/galera/MysqL-bin #如果不接从库，注释掉 #log_slave_updates=1 #如果不接从库，注释掉 query_cache_size=0 #关闭查询缓存 wsrep_on=ON #开启全同步复制模式 wsrep_provider=/usr/lib64/galera/libgalera_smm.so#galera library wsrep_cluster_name=MariaDB-galera-Cluster wsrep_cluster_address="gcomm://192.168.1.104,192.168.1.106" #galera cluster URL wsrep_node_name=mariadb-a03 wsrep_node_address=192.168.1.104 binlog_format=row default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 #主键自增模式修改为交叉模式 wsrep_slave_threads=8 #开启并行复制线程，根据cpu核数设置 innodb_flush_log_at_trx_commit=0 #事务提交每隔1秒刷盘 innodb_buffer_pool_size=2G wsrep_sst_method=rsync [embedded] [mariadb] [mariadb-10.1]
# 上面配置使用的是rsync方式同步数据，如果要使用xtrabackup方式（建议使用），需要设置：
wsrep_sst_method=xtrabackup-v2 #默认是rsync全量拷贝，但是需要在donor节点上执行全局读锁(flushtables with read lock)，建议采用xtrabackup热备份方式，只有在备份.frm表结构文件才会锁表
2.192.168.1.105节点的/etc/my.cnf.d/server.cnf文件内容：
[root@mariadb-a04 ~]# cat /etc/my.cnf.d/server.cnf | grep -v "#" | grep -v "^$" [server] [MysqLd] server_id=129 datadir=/app/galera user=MysqL skip-external-locking skip-name-resolve character-set-server=utf8 [galera] wsrep_causal_reads=ON wsrep_provider_options="gcache.size=4G" wsrep_certify_nonPK=ON query_cache_size=0 wsrep_on=ON wsrep_provider=/usr/lib64/galera/libgalera_smm.so wsrep_cluster_name=MariaDB-galera-Cluster wsrep_cluster_address="gcomm://192.168.1.104,192.168.1.106" wsrep_node_name=mariadb-a04 wsrep_node_address=192.168.1.105 binlog_format=row default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 wsrep_slave_threads=8 innodb_flush_log_at_trx_commit=0 innodb_buffer_pool_size=2G wsrep_sst_method=rsync [embedded] [mariadb] [mariadb-10.1]
3.192.168.1.106节点的/etc/my.cnf.d/server.cnf文件内容：
[root@mariadb-a05 yum.repos.d]# cat /etc/my.cnf.d/server.cnf | grep -v "#" | grep -v "^$" [server] [MysqLd] server_id=130 datadir=/app/galera user=MysqL skip-external-locking skip-name-resolve character-set-server=utf8 [galera] wsrep_causal_reads=ON wsrep_provider_options="gcache.size=4G" wsrep_certify_nonPK=ON query_cache_size=0 wsrep_on=ON wsrep_provider=/usr/lib64/galera/libgalera_smm.so wsrep_cluster_name=MariaDB-galera-Cluster wsrep_cluster_address="gcomm://192.168.1.104,192.168.1.106" wsrep_node_name=mariadb-a05 wsrep_node_address=192.168.1.106 binlog_format=row default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 wsrep_slave_threads=8 innodb_flush_log_at_trx_commit=0 innodb_buffer_pool_size=2G wsrep_sst_method=rsync [embedded] [mariadb] [mariadb-10.1]
MariaDB一个节点初始化安装（192.168.1.104）：
# MysqL_install_db --defaults-file=/etc/my.cnf.d/server.cnf --user=MysqL
在192.168.1.104节点上通过bootstrap启动（第一次启动一定要使用--wsrep-new-cluster，再次启动就不需要）
MysqLd_safe --defaults-file=/etc/my.cnf.d/server.cnf --user=MysqL --wsrep-new-cluster &
在192.168.1.104节点上设置root密码以及安全设置（192.168.1.104,192.168.1.106）
/usr/bin/MysqL_secure_installation 或 MysqL_secure_installation
在192.168.1.105,192.168.1.106节点启动MariaDB：
MysqLd_safe --defaults-file=/etc/my.cnf.d/server.cnf --user=MysqL &
验证操作
登录三个节点查看
192.168.1.104节点： MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 1 row in set (0.00 sec) MariaDB [(none)]> show global status like 'ws%'; +------------------------------+-------------------------------------------------------------+ | Variable_name | Value | +------------------------------+-------------------------------------------------------------+ | wsrep_apply_oooe | 0.000000 | | wsrep_apply_oool | 0.000000 | | wsrep_apply_window | 1.000000 | | wsrep_causal_reads | 11 | | wsrep_cert_deps_distance | 1.000000 | | wsrep_cert_index_size | 2 | | wsrep_cert_interval | 0.000000 | | wsrep_cluster_conf_id | 3 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid |3108c722-ff29-11e6-a31f-bb500598d033 | | wsrep_cluster_status | Primary | | wsrep_commit_oooe | 0.000000 | | wsrep_commit_oool | 0.000000 | | wsrep_commit_window | 1.000000 | | wsrep_connected | ON | | wsrep_desync_count | 0 | | wsrep_evs_delayed | | | wsrep_evs_evict_list | | | wsrep_evs_repl_latency | 0/0/0/0/0 | | wsrep_evs_state | OPERATIONAL | | wsrep_flow_control_paused | 0.000000 | | wsrep_flow_control_paused_ns | 0 | | wsrep_flow_control_recv | 0 | | wsrep_flow_control_sent | 0 | | wsrep_gcomm_uuid |3107a278-ff29-11e6-96d3-374133af7e21 | | wsrep_incoming_addresses | 192.168.1.105:3306,192.168.1.106:3306,192.168.1.104:3306| | wsrep_last_committed | 3 | | wsrep_local_bf_aborts | 0 | | wsrep_local_cached_downto | 1 | | wsrep_local_cert_failures | 0 | | wsrep_local_commits | 0 | | wsrep_local_index | 2 | | wsrep_local_recv_queue | 0 | | wsrep_local_recv_queue_avg | 0.000000 | | wsrep_local_recv_queue_max | 1 | | wsrep_local_recv_queue_min | 0 | | wsrep_local_replays | 0 | | wsrep_local_send_queue | 0 | | wsrep_local_send_queue_avg | 0.000000 | | wsrep_local_send_queue_max | 1 | | wsrep_local_send_queue_min | 0 | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_local_state_uuid |3108c722-ff29-11e6-a31f-bb500598d033 | | wsrep_protocol_version | 7 | | wsrep_provider_name | galera | | wsrep_provider_vendor | Codership Oy<info@codership.com> | | wsrep_provider_version | 25.3.19(r3667) | | wsrep_ready | ON | | wsrep_received | 10 | | wsrep_received_bytes | 806 | | wsrep_repl_data_bytes | 1044 | | wsrep_repl_keys | 3 | | wsrep_repl_keys_bytes | 93 | | wsrep_repl_other_bytes | 0 | | wsrep_replicated | 3 | | wsrep_replicated_bytes | 1329 | | wsrep_thread_count | 9 | +------------------------------+-------------------------------------------------------------+ 58 rows in set (0.00 sec)
注释：
wsrep_cluster_status为Primary，表示节点为主节点，正常读写。
wsrep_ready为ON，表示集群正常运行。
wsrep_cluster_size为3，表示集群有三个节点。
创建数据库测试
192.168.1.104节点： [root@mariadb-a03 my.cnf.d]# MysqL -uroot –pxxxxxx MariaDB [(none)]> create databasetest_db; Query OK,1 row affected (0.01 sec)
192.168.1.105节点查看： [root@mariadb-a04 my.cnf.d]# MysqL -uroot -pxxxxxx MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | MysqL | | performance_schema | | test_db | +--------------------+
192.168.1.106节点查看： [root@mariadb-a05 my.cnf.d]# MysqL -uroot -pxxxxxx MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | MysqL | | performance_schema | | test_db | +--------------------+ 4 rows in set (0.00 sec)
可以看到集群正常使用。
创建MyISAM表测试
[root@mariadb-a03 my.cnf.d]# MysqL -uroot –pxxxxxx MariaDB [(none)]> use test_db; Database changed MariaDB [test_db]> create table myisam_tbl (id int,name text) ENGINE MyISAM; Query OK,0 rows affected (0.01 sec) MariaDB [test_db]> insert into myisam_tbl values(1,'hive'); Query OK,1 row affected (0.00 sec) MariaDB [test_db]> insert into myisam_tbl values(2,'hbase'); Query OK,1 row affected (0.00 sec)
其他节点查看：
[root@mariadb-a04 my.cnf.d]# MysqL -uroot -pxxxxxx MariaDB [(none)]> use test_db; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [test_db]> select * from myisam_tbl; Empty set (0.00 sec) [root@mariadb-a05 my.cnf.d]# MysqL -uroot –pxxxxxx MariaDB [(none)]> use test_db; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [test_db]> select * from myisam_tbl; Empty set (0.00 sec)
可以看到MyISAM存储的表，galera不支持同步。它仅支持XTradB/ InnoDB存储引擎（虽然有对MyISAM实验支持，具体看wsrep_replicate_myisam系统变量）。
验证InnoDB存储的表
[root@mariadb-a03 my.cnf.d]# MysqL -uroot –pxxxxxx MariaDB [test_db]> create table innodb_tbl(id int,name text) ENGINE InnoDB; Query OK,0 rows affected (0.04 sec) MariaDB [test_db]> insert into innodb_tbl values(1,1 row affected (0.00 sec) MariaDB [test_db]> insert into innodb_tbl values(2,1 row affected (0.00 sec) MariaDB [test_db]>
其他节点查看：
[root@mariadb-a04 my.cnf.d]# MysqL -uroot -pxxxxxx MariaDB [(none)]> use test_db; Reading table information for completion oftable and column names You can turn off this feature to get aquicker startup with -A Database changed MariaDB [test_db]> select * from innodb_tbl; +------+-------+ | id | name | +------+-------+ | 1 | hive | | 2 | hbase | +------+-------+ 2 rows in set (0.00 sec) [root@mariadb-a05 my.cnf.d]# MysqL -uroot –pxxxxxx MariaDB [(none)]> use test_db; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [test_db]> select * from innodb_tbl; +------+-------+ | id | name | +------+-------+ | 1 | hive | | 2 | hbase | +------+-------+ 2 rows in set (0.00 sec)
模拟节点故障
将192.168.1.104数据库停止掉：
[root@mariadb-a03 system]# MysqLadmin -uroot -p "shutdown"
然后在其他节点192.168.1.105执行：
MariaDB [test_db]> show global status like 'wsrep%'; +------------------------------+-----------------------------------------------+ | Variable_name | Value | +------------------------------+-----------------------------------------------+ | wsrep_apply_oooe | 0.000000 | | wsrep_apply_oool | 0.000000 | | wsrep_apply_window | 1.000000 | | wsrep_causal_reads | 26 | | wsrep_cert_deps_distance | 1.142857 | | wsrep_cert_index_size |6 | | wsrep_cert_interval | 0.000000 | | wsrep_cluster_conf_id | 6 | | wsrep_cluster_size | 2 | | wsrep_cluster_state_uuid |3108c722-ff29-11e6-a31f-bb500598d033 | | wsrep_cluster_status | Primary | | wsrep_commit_oooe | 0.000000 | | wsrep_commit_oool | 0.000000 | | wsrep_commit_window | 1.000000 | | wsrep_connected | ON | | wsrep_desync_count | 0 | | wsrep_evs_delayed | | | wsrep_evs_evict_list | | | wsrep_evs_repl_latency |0.000403989/0.000656768/0.0012094/0.0003239/4 | | wsrep_evs_state | OPERATIONAL | | wsrep_flow_control_paused | 0.000000 | | wsrep_flow_control_paused_ns | 0 | | wsrep_flow_control_recv | 0 | | wsrep_flow_control_sent | 0 | | wsrep_gcomm_uuid | 0ce8537e-ff2a-11e6-b037-8a383b6a8db5 | | wsrep_incoming_addresses | 192.168.1.105:3306,192.168.1.106:3306 | | wsrep_last_committed | 10 | | wsrep_local_bf_aborts | 0 | | wsrep_local_cached_downto | 4 | | wsrep_local_cert_failures | 0 | | wsrep_local_commits | 0 | | wsrep_local_index | 0 | | wsrep_local_recv_queue | 0 | | wsrep_local_recv_queue_avg | 0.000000 | | wsrep_local_recv_queue_max | 1 | | wsrep_local_recv_queue_min | 0 | | wsrep_local_replays | 0 | | wsrep_local_send_queue | 0 | | wsrep_local_send_queue_avg | 0.000000 | | wsrep_local_send_queue_max | 1 | | wsrep_local_send_queue_min | 0 | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_local_state_uuid |3108c722-ff29-11e6-a31f-bb500598d033 | | wsrep_protocol_version | 7 | | wsrep_provider_name | galera | | wsrep_provider_vendor | Codership Oy<info@codership.com> | | wsrep_provider_version | 25.3.19(r3667) | | wsrep_ready | ON | | wsrep_received | 14 | | wsrep_received_bytes | 3908 | | wsrep_repl_data_bytes | 0 | | wsrep_repl_keys | 0 | | wsrep_repl_keys_bytes | 0 | | wsrep_repl_other_bytes | 0 | | wsrep_replicated | 0 | | wsrep_replicated_bytes | 0 | | wsrep_thread_count | 9 | +------------------------------+-----------------------------------------------+
此时集群为自动将192.168.1.104故障节点剔除掉，并且正常提供服务。
最后我们恢复失败的节点：
[root@mariadb-a03 system]# MysqLd_safe --defaults-file=/etc/my.cnf.d/server.cnf --user=MysqL &
再次查看集群环境：
MariaDB [test_db]> SHOW STATUS LIKE 'wsrep_cluster_size'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 1 row in set (0.00 sec
模拟脑裂后的处理
下面模拟在网络抖动发生丢包的情况下，两个节点失联导致脑裂。首先，在192.168.1.105和192.168.1.106两个节点上分别执行：
iptables -A INPUT -p tcp --sport 4567 -j DROP
iptables -A INPUT -p tcp --dport 4567 -j DROP
以上命令用来禁止wsrep全同步复制4567端口通信。
然后我们在192.168.1.104节点查看：
MariaDB [(none)]> show global statuslike 'ws%'; 可以看到下面的几个值： wsrep_cluster_size 1 wsrep_cluster_status non-Primary wsrep_ready OFF MariaDB [(none)]> use test_db; ERROR 1047 (08S01): WSREP has not yetprepared node for application use MariaDB [(none)]> select@@wsrep_node_name; ERROR 1205 (HY000): Lock wait timeoutexceeded; try restarting transaction
现在已经出现脑裂的情况，并且集群无法执行任何命令。
为了解决这个问题，可以执行：
set global wsrep_provider_options="pc.bootstrap=true";
通过这个命令来强制恢复出现脑裂的节点。
下面我们来验证一下：
MariaDB [(none)]> select @@wsrep_node_name; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction MariaDB [(none)]> set global wsrep_provider_options="pc.bootstrap=true"; Query OK,0 rows affected (0.00 sec) MariaDB [(none)]> select @@wsrep_node_name; +-------------------+ | @@wsrep_node_name | +-------------------+ | mariadb-a03 | +-------------------+ 1 row in set (0.27 sec) MariaDB [(none)]> use test_db; Reading table information for completion oft able and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [test_db]> show tables; +-------------------+ | Tables_in_test_db | +-------------------+ | innodb_tbl | | myisam_tbl | +-------------------+
最后我们将节点192.168.1.105和192.168.1.106恢复一下，只要清理一下iptables表即可(因为我的是测试环境，生产环境需要删除上面的规则即可)：
iptables –F
各个节点验证一下：
192.168.1.104： MariaDB [test_db]> SHOW STATUS LIKE 'wsrep_cluster_size'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 1 row in set (0.00 sec) 192.168.1.105： MariaDB [(none)]> select @@wsrep_node_name; +-------------------+ | @@wsrep_node_name | +-------------------+ | mariadb-a04 | +-------------------+
避免脏读
galera Cluster不是真正意义上的全同步复制，存在延迟。我们可以在一个节点上面执行FLUSH TABLES WITH READ LOCK;全局读锁。
然后在其他节点执行写操作，观察延迟情况。
比如我们在192.168.1.106节点执行全局读锁设置：
MariaDB [test_db]> flush tables with read lock; Query OK,0 rows affected (0.00 sec) MariaDB [test_db]> select * from innodb_tbl; +------+------+ | id | name | +------+------+ | 1 | hive | +------+------+ 1 row in set (0.00 sec) 然后在192.168.1.104节点插入操作： MariaDB [test_db]> select @@wsrep_node_name; +-------------------+ | @@wsrep_node_name | +-------------------+ | mariadb-a03 | +-------------------+ 1 row in set (0.00 sec) MariaDB [test_db]> insert into innodb_tbl values(2,1 row affected (0.00 sec) MariaDB [test_db]> select * from innodb_tbl; +------+-------+ | id | name | +------+-------+ | 1 | hive | | 2 | hbase | +------+-------+ 2 rows in set (0.00 sec) 在节点192.168.1.106上测试查询操作： MariaDB [test_db]> select * from innodb_tbl; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
这里之所以没有读取到脏数据，是因为我在MariaDB配置文件中设置了wsrep_causal_reads=ON;
我们将wsrep_causal_reads修改为0或OFF来看一下效果：
MariaDB [test_db]> set wsrep_causal_reads=0; Query OK,0 rows affected,1 warning (0.00sec) MariaDB [test_db]> select * from innodb_tbl; +------+------+ | id | name | +------+------+ | 1 | hive | +------+------+ 1 row in set (0.00 sec) MariaDB [test_db]>
总结
通过上面的一系列测试，最后总结一下：
1. 在生产环境下应该避免使用大事务，不建议在高并发写入场景下使用galera Cluster架构，会导致集群限流，从而引起整个集群hang住，出现生产故障。针对这种情况可以考虑主从，实现读写分离等手段。
2. 对数据一致性要求较高，并且数据写入不频繁，数据库容量也不大（50GB左右），网络状况良好的情况下，可以考虑使用galera方案
