mysql pxc强一致性集群

JAAT9999 2019-03-12

数据存储与数据库 mysql 数据库 cluster 集群 同步 数据同步 并发控制

image

工作原理:

从上图可以看到当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掉,快速重启,赶紧恢复一个节点提交线上服务,然后再考虑集群其它节点的数据增量的同步等。

登录 后评论
下一篇
corcosa
11843人浏览
2019-10-08
相关推荐
MySQL高可用方案选型参考
1664人浏览
2017-08-02 14:35:00
OLTP应用之MySQL架构选型
691人浏览
2016-02-16 23:49:51
PXC使用介绍
658人浏览
2017-11-12 14:28:00
高可用PXC
795人浏览
2017-11-27 15:20:00
实施PXC 5.7
1478人浏览
2018-01-02 23:08:59
Percona XtraDB Cluster 初探
990人浏览
2017-11-09 05:44:00
MySQL常用集群方案
1266人浏览
2018-07-03 10:14:14
0
0
0
1296