mysql pxc强一致性集群

2021-10-08 10:14:58

mysql pxc强一致性集群

工作原理：

从上图可以看到当client端执行dml操作时，将操作发给server，server的native进程处理请求，client端执行commit，server将复制写数据集发给group(cluster)，cluster中每个动作对应一个GTID，其它server接收到并通过验证(合并数据)后，执行appyl_cb动作和commit_cb动作，若验证没通过，则会退出处理;当前server节点验证通过后，执行commit_cb，并返回，若没通过，执行rollback_cb。只要当前节点执行了commit_cb和其它节点验证通过后就可返回。(节点接收sql 请求后，对于dml 操作，在commit之前，由wsrep API 调用galera 库进行集群内广播，所有其他节点验证成功后事务在集群所有节点进行提交，反之roll back。在一个事务提交的过程，Node1提交一个事物，必须要所有的节点通过了这个事务的请求，并且返回成功（ok）或者失败（conflict）信号之后，才真正的commit之后返回结果给用户，但是这里注意，最后在其它节点apply过程，并不会影响到给用户返回结果的过程。)

  1. 本地执行：这个阶段，是事务执行的最初阶段，可以说，这个阶段的执行过程，与单点MySQL执行没什么区别，并发控制当然就是数据库的并发控制了，而不是Galera Cluster的并发控制了。
  2. 写集发送：在执行完之后，就到了提交阶段，提交之前首先将产生的写集广播出去，而为了保证全局数据的一致性，在写集发送时，需要串行，这个就属于Galera Cluster并发控制的一部分了。
  3. 写集验证：这个阶段，就是我们通常说的Galera Cluster的验证了，验证是将当前的事务，与本地写集验证缓存集来做验证，通过比对写集中被影响的数据库KEYS，来发现有没有相同的，来确定是不是可以验证通过，那么这个过程，也是串行的。
  4. 写集提交：这个阶段，是一个事务执行时的最后一个阶段了，验证完成之后，就可以进入提交阶段了，因为些时已经执行完了的，而提交操作的并发控制，是可以通过参数来控制其行为的，即参数repl.commit_order，如果设置为3，表示提交就是串行的了，而这也是本人所推荐的（默认值）的一种设置，因为这样的结果是，集群中不同节点产生的Binlog是完全一样的，运维中带来了不少好处和方便。其它值的解释，以后有机会再做讲解。
  5. 写集APPLY：这个阶段，与上面的几个在流程上不太一样，这个阶段是从节点做的事情，从节点只包括两个阶段，即写集验证和写集APPLY，写集APPLY的并发控制，是与参数wsrep_slave_threads有关系的，本身在验证之后，确定了相互的依赖关系之后，如果确定没有关系的，就可以并行了，而并行度，就是参数wsrep_slave_threads的事情了。wsrep_slave_threads可以参照参数wsrep_cert_deps_distance来设置。

PXC局限性：

任何命令执行出现unkown command ，表示出现脑裂，集群两节点间4567端口连不通，无法提供对外服务。执行SET GLOBAL wsrep_provider_options="pc.ignore_sb=true"; 恢复业务
1，目前的复制仅仅支持InnoDB存储引擎。任何写入其他引擎的表，包括mysql.*表将不会复制。但是DDL语句会被复制的，因此创建用户将会被复制，但是insert into mysql.user…将不会被复制的。
2，pxc结构里面必须有主键，如果没有主建，有可能会造成集中每个节点的Data page里的数据不一样
3，在多主环境下LOCK/UNLOCK TABLES不支持。以及锁函数GET_LOCK(), RELEASE_LOCK()…,
4，查询日志不能保存在表中。如果开启查询日志，只能保存到文件中。
5，允许最大的事务大小由wsrep_max_ws_rows和wsrep_max_ws_size定义。任何大型操作将被拒绝。如大型的LOAD DATA操作。,
6，由于集群是乐观的并发控制，事务commit可能在该阶段中止。如果有两个事务向在集群中不同的节点向同一行写入并提交，失败的节点将中止。对于集群级别的中止，集群返回死锁错误代码(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
7，XA事务不支持，由于在提交上可能回滚。
8，整个集群的写入吞吐量是由最弱的节点限制，如果有一个节点变得缓慢，那么整个集群将是缓慢的。为了稳定的高性能要求，所有的节点应使用统一的硬件。
9，集群节点建议最少3个。
10，不要使用binlog-do-db和binlog-ignore-db, 这些选项仅支持DML语句, 不支持DDL语句, 使用这些选项可能会引起数据的错乱。

PXC工作端口号：

3306:数据库对外服务的端口号
4444:请求SST（全量同步），在新节点加入时起作用
4567:组成员之间沟通的端口
4568:传输IST(增量同步 )，节点下线，重启加入时起作用
pxc cluster相互通讯的端口：
2）Port for group communication, default 4567. It can be changed by the option:
wsrep_provider_options ="gmcast.listen_addr=tcp://0.0.0.0:4010; "
用于SST传送的端口：
3）Port for State Transfer, default 4444. It can be changed by the option:
wsrep_sst_receive_address=10.11.12.205:5555
用于IST传送的端口：
4）Port for Incremental State Transfer, default port for group communication + 1 (4568). It can be changed by the option:
wsrep_provider_options = "ist.recv_addr=10.11.12.206:7777; "

状态机变化阶段(wsrep_local_state_comment)：

1）OPEN: 节点启动成功，尝试连接到集群，如果失败则根据配置退出或创建新的集群
2）PRIMARY: 节点处于集群PC(primary component)中，尝试从集群中选取donor进行数据同步
3）JOINER: 节点处于等待接收/接收数据文件状态，数据传输完成后在本地加载数据
4）JOINED: 节点完成数据同步工作，尝试保持和集群进度一致
5）SYNCED：节点正常提供服务：数据的读写，集群数据的同步，新加入节点的sst请求
6）DONOR(贡献数据者)：节点处于为新节点准备或传输集群全量数据状态，对客户端不可用

安装部署：

centos 6.5+ percona xtradb cluster 5.6
192.168.2.128 slave1
192.168.2.129 slave2
192.168.2.130 slave3

在slave1，slave2，slave3上分别执行：
[root@slave1 ~]#rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
[root@slave1 ~]#rpm -ivh https://www.percona.com/redir/downloads/percona-release/redhat/latest/percona-release-0.1-4.noarch.rpm
[root@slave1 ~]#yum -y install Percona-XtraDB-Cluster-56

在slave1上执行：

[root@slave1 ~]# mv /var/lib/mysql   /data                #如果数据库不放在默认/var/lib下，要先移动之前的安装文件然后才能重新启动。不然启动会报错：
[root@slave1 ~]# vi /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
user=mysql
wsrep_provider=/usr/lib64/libgalera_smm.so
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_address=gcomm://192.168.2.128,192.168.2.129,192.168.2.130
binlog_format=ROW
default_storage_engine=InnoDB
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node #1 address
wsrep_node_address=192.168.2.128
# SST method
wsrep_sst_method=xtrabackup-v2
# Cluster name
wsrep_cluster_name=my_cluster
# Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
wsrep_provider_options="gcache.size=2000M"
wsrep_slave_threads=16
##########mysq#########
innodb_flush_log_at_trx_commit=2

[root@slave1 ~]#/etc/init.d/mysql bootstrap-pxc                //初始化节点1        
mysql> show status like 'wsrep%';                        //查看状态，保证以下几项没有问题。
+----------------------------+--------------------------------------+
| Variable_name              | Value                                |
+----------------------------+--------------------------------------+
| wsrep_local_state_uuid     | c2883338-834d-11e2-0800-03c9c68e41ec |
...
| wsrep_local_state          | 4                                    |
| wsrep_local_state_comment  | Synced                               |
...
| wsrep_cluster_size         | 1                                    |
| wsrep_cluster_status       | Primary                              |
| wsrep_connected            | ON                                   |
...
| wsrep_ready                | ON                                   |
+----------------------------+--------------------------------------+

mysql@slave1> UPDATE mysql.user SET password=PASSWORD("123456") where user='root';
mysql@slave1> FLUSH PRIVILEGES;
mysql@slave1> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 's3cret';
mysql@slave1> GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
mysql@slave1> FLUSH PRIVILEGES;


配置节点2，在slave2上操作：
[root@slave2 ~]# vi /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
user=mysql
wsrep_provider=/usr/lib64/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.2.128,192.168.2.129,192.168.2.130
binlog_format=ROW
default_storage_engine=InnoDB
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node #2 address
wsrep_node_address=192.168.2.129
wsrep_cluster_name=my_cluster
# SST method
wsrep_sst_method=xtrabackup-v2
#Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
wsrep_provider_options="gcache.size=2000M"
wsrep_slave_threads=16
innodb_flush_log_at_trx_commit=2
[root@slave2 ~]# /etc/init.d/mysql start
mysql> show status like 'wsrep%';


配置节点3，在slave3上操作
[root@slave3 ~]# vi /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
user=mysql
wsrep_provider=/usr/lib64/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.2.128,192.168.2.129,192.168.2.130
binlog_format=ROW
default_storage_engine=InnoDB
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node #2 address
wsrep_node_address=192.168.2.130
wsrep_cluster_name=my_cluster
# SST method
wsrep_sst_method=xtrabackup-v2
#Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
wsrep_provider_options="gcache.size=2000M"
wsrep_slave_threads=16
innodb_flush_log_at_trx_commit=2
[root@slave2 ~]# /etc/init.d/mysql start
mysql> show status like 'wsrep%';

验证：在其中任意节点新建表插入数据，在其他库上查看是否已经同步。

启动关闭：

当galera cluster集群单个节点或所有节点停机情况分析
单个节点停机
节点停机重启，重新加入集群，通过IST增量同步数据，来保持集群数据的一致性。IST的实现由wsrep_provider_options="gcache.size=1G"参数决定，一般设置为1G。参数大小由什么决定，根据停机时间，若停机一小时，需要确认一小时产生多大的binlog来算出参数大小。如果停机时间过长，部分数据gcache没有，此时该节点SST全量同步数据。

  1. 所有节点关闭，应采用轮巡滚动关闭的方式：a节点关闭修复，加回集群；b节点关闭修复，加回集群...原则就是保持cluster中最少一个成员存活，进行滚动重启。
    3，集群所有节点都关闭了，没有存活的节点的情况：每个节点数据库关闭后，都会保存最后一个GTID，启动集群时要先启动最后一个关闭的节点，启动顺序和关闭顺序相反。
  2. 避免关闭和启动节点时数据丢失
    3.1 原则保持cluster集群中最少有一个成员存货，然后进行滚动重启

3.2 利用主从的概念，把一个从节点转化为PXC/Galera集群中的节点

增加或者删除节点：

增加节点：
1，如果是之前旧节点恢复了只需要启动就可以了，会自动加入集群。
2，如果是新搭建的机器，还是按照之前安装集群的方法装好这台机器，然后修改其他节点的/etc/my.cnf中的wsrep_cluster_address=gcomm://，修改其他节点的my.cnf文件后不需要重启。

删除节点：
直接停掉该节点的mysql，修改my.cnf中wsrep_cluster_address=gcomm://，然后修改其他节点/etc/my.cnf把停掉的节点ip在wsrep_cluster_address=gcomm://中删除掉，修改完my.cnf后不需要重启。

PXC集群恢复排错：

gvwstate.dat : This file is used for Primary Component recovery feature
grastate.dat :This file contains the Galera state information.

情景1：三个节点挂了2个(正常关闭):
node1，node2挂了，node3存活
在node1，node2上执行:

#service mysql start --wsrep_sst_donor=node3

注意：当某个node被宣威donor时，使用rsync或者dump时，该节点无法提供服务。即使使用xtrabackup这个节点性能也会收到影响，建议手动选择donar，避免高负载的机器被用来做donar，不指定则随机选择。

情景2：三个节点全部挂了(正常关闭):
在node1上执行:

#/etc/init.d/mysql bootstrap-pxc

在node2，node3上执行:

#/etc/init.d/mysql start

情景3：node1，node2不见了(非正常关闭)，node3无法单独形成仲裁，同时它会变成non-primary状态并且不会处理任何请求。
在node3上执行命令:

mysql> select * from test.t1;
ERROR 1047 (08S01): Unknown command

查看节点日志：
140814 0:42:13 [Note] WSREP: commit failed for reason: 3
140814 0:42:13 [Note] WSREP: conflict state: 0
140814 0:42:13 [Note] WSREP: cluster conflict due to certification failure for threads:
140814 0:42:13 [Note] WSREP: Victim thread:
THD: 7, mode: local, state: executing, conflict: cert failure, seqno: -1
SQL: insert into t values (1)

解决办法：
在node3上执行(告诉node3你可以自己组成一个新集群)：

SET GLOBAL wsrep_provider_options='pc.bootstrap=true';

注意：在执行命令之前一定要确认node1，node2确实挂了，否则会造成数据不一致。

情景4，所有节点突然掉电

#cat  /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 220dcdcb-1629-11e4-add3-aec059ad3734
seqno: -1
cert_index:

因为突然掉电，不确定哪个节点的数据是最新的，查看gvwstate.dat文件找出最新的seqno
#cat /var/lib/mysql/gvwstate.dat  
my_uuid: 76de8ad9-2aac-11e4-8089-d27fd06893b9
#vwbeg
view_id: 3 6c821ecc-2aac-11e4-85a5-56fe513c651f 3
bootstrap: 0
member: 6c821ecc-2aac-11e4-85a5-56fe513c651f 0
member: 6d80ec1b-2aac-11e4-8d1e-b2b2f6caf018 0
member: 76de8ad9-2aac-11e4-8089-d27fd06893b9 0
#vwend

实际上在 PXC5.6.19以后的系统会根据这个文件自动找到seqno最大的节点，从而自动启动数据恢复过程，不需要人工干预。如果实在不行就在该文件中找到最新的节点，手动在该节点上执行SET GLOBAL wsrep_provider_options='pc.bootstrap=true'（同情景2处理方法一样）;

两节点集群排错：
解决方法：
在其中一个节点上初始化所有集群，并且将该节点设为新的Primary Component

mysql> SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';
如果你想该节点可以同时处理请求，执行如下命令：
mysql> SET GLOBAL wsrep_provider_options='pc.ignore_sb=TRUE';

注意：在多主节点中执行这个很危险，会有脑裂的风险。所以该命令尽量只在主从环境中执行。

perconaXtraDB cluster中有两种参数可用于在通信断开时防止节点降级为non-primary状态。分别为pc.ignore_quorum和pc.ignore_sb。
pc.ignore_quorum参数设置为true的时候，节点忽略quorum算法，节点正常运行。
pc.ignore_sb是当节点通讯关闭，发生脑裂时，忽略为防止脑裂时数据不一致而无法执行语句的机制，可以在各个节点正常运行命令。

例1：
在各节点my.cnf中加入wsrep_provider_options = "pc.ignore_quorum =true" 参数，断开节点间网络。
可以看到两个节点都没有降级到non-primary状态，不会降级并且可以各自处理请求。但是当网络恢复之后，点不会自动恢复到同步状态，不会发生数据同步，双节点各自形成一个cluter。
如果要恢复集群模式，只能通过SST方式将数据同步，但是会造成一个节点的数据丢失！

例2：
在各节点my.cnf中加入wsrep_provider_options = "pc.ignore_sb = true" 参数，断开节点间网络。
可以看到两个节点都没有降级到non-primary状态，向两个节点插入不同的数据后恢复网络,集群不会恢复到原来的状态,
重启备节点，由于备节点多插入了数据，seqno比主节点的高，所以重启失败。节点间无法构成集群，只能删除数据重新进行SST。

重要参数：

IST的实现是由wsrep_provider_options="gcache.size=1G"参数决定，参数大小是由什么决定的，根据停机时间，若停机一小时binlog为1G，则gcache.size设置为1G，gcache是需要实际内存分配的，也不能设置太大，否则会出现oom-kill
wsrep_flow_control_paused_ns :表示当前节点落后集群的程度，0.0---1.0。0.0表示为没有落后。1.0表示为flow control已经停止 。如果落后太厉害要适当增加wsrep_slave_threads数。
wsrep_cert_deps_distance: 表示当前节点平均时间内并行执行的事务数。这个可以作为wsrep_slave_threads的参考，同时并发量大的时候这个值也会大。
wsrep_flow_control_sent：表示flow_control发出FC_PAUSE事件的次数，暂停的次数越多，表示接受到的请求频繁堵满slave队列。这种情况下不是队列长度不足就是机器性能太差，如果集群中多个机器出现这种情况，则考虑调整slave队列长度相关参数,如gcs.fc_limit等
wsrep_local_recv_queue_avg：本地节点平均的接收队列长度，如果这个参数不为0.0，表示接收来的 数据不能被及时应用（立即应用了则不会进入队列)
wsrep_local_send_q_avg：表示本地节点发送数据的队列长度，如果这个参数不为0.0，表示向外发送数据的速度比较慢，有堆积。
wsrep_slave_threads：建议每core启动4个复制线程
wsrep_local_cert_failures ：同步过程中节点认证失败计数，冲突来自本地提交的事务和同步队列中事务存在锁冲突，则本地验证失败（保证全局数据一致性）
wsrep_local_bf_aborts ：强制放弃，本地事务和同步队列中正在执行的事务存在锁冲突时，将强制保证先提交的事务成功，后者回滚后报错
wsrep_last_committed : 已经提交事务数目，所有节点之间相差不大，可以用来计算延迟

wsrep_provider_options
该参数是一个字符串，包含了group communication system中很多参数设置，配置时使用分号隔开：
wsrep_provider_options="key_a=value_a;key_b=value_b;key_c=value_c"，

evs.send_window：节点一次可以发送的消息数目，默认4
evs.user_send_window：其与evs.send_window之间的差别类似于max_connections与max_user_connection，默认2
gcs.fc_factor：flow control参数，默认0.5
gcs.fc_limit：flow control参数，流量控制大小限制，默认16
FC问题处理：
注意：这两个参数的意义是，当从节点堆积的事务数量超过gcs.fc_limit的值时，从节点就发起一个Flow Control，而当从节点堆积的事务数小于gcs.fc_limit * gcs.fc_factor时，发起Flow Control的从节点再发起一个解除的消息，让整个集群再恢复。
发送FC消息的节点，硬件有可能出现问题了，比如IO写不进去，很慢，CPU异常高等
发送FC消息的节点，本身数据库压力太高，比如当前节点承载太多的读，导致机器Load高，IO压力大等等。
发送FC消息的节点，硬件压力都没有太大问题，但做得比较慢，一般原因是主库并发高，但从节点的并发跟不上主库，那么此时可能需要观察这两个节点的并发度大小，可以参考状态参数wsrep_cert_deps_distance的值，来调整从节点的wsrep_slave_threads，此时应该是可以解决或者缓解的。假设集群每个节点的硬件资源都是相当的，那么主库可以执行完，从库为什么做不过来？那么一般思路就是像处理主从复制的延迟问题一样。
检查存不存在没有主键的表，因为Galera的复制是行模式的，所以如果存在这样的表时，主节点是通过语句来修改的，比如一个更新语句，更新了全表，而从节点收到之后，就会针对每一行的Binlog做一次全表扫描，这样导致这个事务在从节点执行，比在主节点执行慢十倍，或者百倍，从而导致从节点堆积进而产生FC。可以看出，其实这些方法，都是用来解决主从复制延迟的方法，没什么两样，在了解Flow Control的情况下，解决它并不是难事儿。
gcs.fc_master_slave：flow control参数，默认NO
gcs.recv_q_hard_limit：接收队列的占用的最大内存，默认LLONG_MAX
gcs.recv_q_soft_limit：当接收队列占用内存超过(gcs.recv_q_hard_limit*gcs.recv_q_soft_limit),复制被延迟，默认0.25
gmcast.listen_addr：节点用于接收其它节点消息的地址，默认tcp://0.0.0.0:4567
pc.checksum：是否对发送的消息做checksum，默认true
pc.ignore_sb：是否忽略split brain，默认false

注意：Galera flow control
galera是同步复制（虚拟同步）方案，事务在本地节点（客户端提交事务的节点）上提交成功时，其它节点保证执行该事务。在提交事务时，本地节点把事务复制到所有节点后，之后各个节点独立异步地进行certification test、事务插入待执行队列、执行事务。然而由于不同节点之间执行事务的速度不一样，长时间运行后，慢节点的待执行队列可能会越积越长，最终可能导致事务丢失。
galera内部实现了flow control，作用就是协调各个节点，保证所有节点执行事务的速度大于队列增长速度，从而避免丢失事务。实现原理和简单：整个galera cluster中，同时只有一个节点可以广播消息（数据），每个节点都会获得广播消息的机会（获得机会后也可以不广播），当慢节点的待执行队列超过一定长度后，它会广播一个FC_PAUSE消息，所以节点收到消息后都会暂缓广播消息，直到该慢节点的待执行队列长度减小到一定长度后，galera cluster数据同步又开始恢复
flow control相关参数：
gcs.fc_limit：待执行队列长度超过该值时，flow control被触发，对于Master-Slave模式(只在一个节点写)的galera cluster，可以配置一个较大的值，对启动多写的galera cluster，较小的值比较合适，因为较大待执行队列长度意味着更大的冲突，默认值16
gcs.fc_factor：当待执行队列长度开始小于(gcs.fc_factor*gcs.fc_limit)时，数据同步恢复,默认0.5
gcs.fc_master_slave：galera cluster是否为Master-Slave模式，默认NO

其余参数：
wsrep_auto_increment_control：控制auto_increment_increment=#nodes和auto_increment_offset=#node_id，默认ON
wsrep_causal_reads：默认是在本地节点读，读到的可能不是最新数据，开启后将读到最新数据，但会增加响应时间，默认OFF
wsrep_certify_nonPK：为没有显示申明主键的表生成一个用于certification test的主键，默认ON
wsrep_cluster_address: 启动节点时需要指定galera cluster的地址,作为cluster中第一个启动的节点
wsrep_cluster_address=gcomm://,对于后续启动的节点，wsrep_cluster_address=gcomm://node1,node2,node3
wsrep_cluster_name: 所有node必须一样, 默认my_test_cluster
wsrep_convert_LOCK_to_trx：将LOCK/UNLOCK TABLES转换成BEGIN/COMMIT，默认OFF
wsrep_data_home_dir：galera会生成一些文件，默认使用mysql_data_dir
wsrep_node_name：节点名称
wsrep_on：session/global,设置为OFF时，事务将不会复制到其他节点，默认ON
wsrep_OSU_method：Online Schema Update设置，TOI/RSU(MySQL >= 5.5.17)，默认TOI
wsrep_provider：libgalera_smm.so的路径，若没有配置，galera复制不会启动
wsrep_retry_autocommit：事务在冲突时重新尝试的次数，默认1
wsrep_slave_threads：并行复制的slave线程数，默认4
wsrep_sst_method：Snapshot State Transter方法：mysqldump/rsync/xt，默认xtrabackup-v2

wsrep_local_state_uuid：应该与wsrep_cluster_state_uuid一致，如363acc29-9160-11e2-0800-4316271a76e4
wsrep_last_committed：已经提交事务数目，所有节点之间相差不大，可以用来计算延迟
wsrep_replicated：从本地节点复制出去的write set数目
wsrep_replicated_bytes：从本地节点复制出去的write set的总共字节数
wsrep_received：本地节点接收来自其他节点的write set数目
wsrep_received_bytes：本地节点接收来自其他节点的write set的总共字节数
wsrep_local_commits：从本地节点发出的write set被提交的数目，不超过wsrep_replicated
wsrep_local_cert_failures：certification test失败的数目
wsrep_local_bf_aborts：certification test通过的write set执行过程中回滚的与其冲突的本地事务
wsrep_local_replays：事务被回滚（bf abort）重做的数目
wsrep_local_send_queue：发送队列的长度
wsrep_local_send_queue_avg：从上次查询状态到目前发送队列的平均长度，>0.0意味着复制过程被节流了
wsrep_local_recv_queue：接收队列的长度
wsrep_local_recv_queue_avg：从上次查询状态到目前接收队列的平均长度，>0.0意味着执行速度小于接收速度
wsrep_flow_control_paused：从上次查询状态到目前处于flow control的时间占比，如0.388129
wsrep_flow_control_sent：从上次查询状态到目前节点发送出的FC_PAUSE消息数目，如1
wsrep_cert_deps_distance：可以并行执行的write set的最大seqno与最小seqno之间的平均差值，如1851.825751
wsrep_apply_oooe：队列中事务并发执行占比，值越高意味着效率越高
wsrep_commit_window：平均并发提交窗口大小
wsrep_local_state：节点的状态,取值1-6
wsrep_local_state_comment：节点的状态描述，比如Synced
wsrep_incoming_addresses：集群中其它节点的地址，多个地址之间用逗号分隔
wsrep_cluster_conf_id：集群节点关系改变的次数（每次增加/删除都会+1）
wsrep_cluster_size：集群节点个数
wsrep_cluster_state_uuid：集群uuid，所有节点应该一样，如：363acc29-9160-11e2-0800-4316271a76e4
wsrep_cluster_status：集群的目前状态，取值：PRIMARY（正常）/NON_PRIMARY（不一致）
wsrep_connected：节点是否连接到集群，取值：ON/OFF
wsrep_local_index：节点id
wsrep_provider_name：默认Galera
wsrep_provider_vendor：默认Codership Oy
wsrep_provider_version：wsrep版本，如：2.2(rXXXX)
wsrep_ready：节点是否可以接受查询了，取值：ON/OFF

如何检查节点是否加入到集群

  1. wsrep_cluster_state_uuid应该与其它所有节点相同
  2. wsrep_cluster_conf_id应该与其它所有节点相同
  3. wsrep_cluster_size应该是所有节点的数目
  4. wsrep_cluster_status取值应该是：Primary
  5. wsrep_ready取值应该是ON
  6. wsrep_connected取值应该是ON

判断复制过程是否出现问题
wsrep_flow_control_paused，正常情况下，其取值应该接近于0.0，大于0.0意味着有'慢节点'影响了集群的速度，可以尝试通过增大wsrep_slave_threads来解决
找出最慢的节点
wsrep_flow_control_sent,wsrep_local_recv_queue_avg两个值最大的节点
参考：galera status，galera monitoring

galera的坑：

DDL执行卡死：在Galera Cluster中执行一个大的改表操作，会导致整个集群在一段时间内卡死在那里，导致线上完全不可服务了。原因还是并发控制，因为提交操作设置为串行的，DDL执行是一个提交的过程，那么串行执行改表，当然执行多久，就卡多久，直到改表执行完，其它事务也就可以继续操作了，这个问题现在没办法解决，但我们长期使用下来发现，小表可以这样直接操作，大一点或者更大的，都是通过osc（pt-online-schema-change）来做，这样就很好的避免了这个问题。

挡我者死：由于Galera Cluster在执行DDL时，是Total Ordered Isolation（wsrep_OSU_method=TOI）的，所以必须要保证每个节点都是同时执行的，当然对于不是DDL的，也是Total Order的，因为每一个事务都具有同一个GTID值，DDL也不例外，而DDL涉及到的是表锁，MDL锁（Meta Data Lock），只要在执行过程中，遇到了MDL锁的冲突，所有情况下，都是DDL优先，将所有的使用到这个对象的事务，统统杀死，不管是读事务，还是写事务，被杀的事务都会报出死锁的异常，并且目前无法解决。

不死之身：继上面的"挡我者死"，如果集群真的被一个DDL卡死了，导致整个集群都动不了了，所有的写请求都Hang住了，直接在每个节点上面输入kill connection_id会出现报错：You are not owner of thread connection_id。这种情况下，要不就等DDL执行完成（所有这个数据库上面的业务都处于不可服务状态），要不就将数据库直接Kill掉，快速重启，赶紧恢复一个节点提交线上服务，然后再考虑集群其它节点的数据增量的同步等。

上一篇：HYPER-V RTM版安装


下一篇：C语言及程序设计初步例程-27 条件运算符和条件表达式