Galera---> PXC or MGC部署

作者: 丶Daniel | 来源:发表于2019-12-10 16:31 被阅读0次

Percona XtraDB Cluster5.7部署

环境信息

ip地址:

pxc01:10.105.2.21 pxc02:10.105.2.22 pxc03:10.105.2.23

拓扑图:

image.png

下载：

登录官方网站：https://www.percona.com/

下载pxc 组件rpm包

注：也可以通过安装YUM仓库进行在线安装

安装YUM仓库：

sudo yum install [https://repo.percona.com/yum/percona-release-latest.noarch.rpm](https://repo.percona.com/yum/percona-release-latest.noarch.rpm)

在线YUM安装：

sudo yum install Percona-XtraDB-Cluster-57

配置：
创建（自定义）数据日志临时文件夹

[root@pxc01 pxc]# mkdir /opt/mysql/{data,logs,tmp} -p
[root@pxc01 pxc]# chown -R mysql.mysql /opt/mysql/
[root@pxc01 pxc]# ll /opt/mysql/
total 0
drwxr-xr-x 2 mysql mysql 6 Nov 23 19:14 data
drwxr-xr-x 2 mysql mysql 6 Nov 23 19:14 logs
drwxr-xr-x 2 mysql mysql 6 Nov 23 19:14 tmp

配置文件修改

pxc01配置文件

pxc01配置文件
[root@pxc01 pxc]#  cp /etc/percona-xtradb-cluster.conf.d/wsrep.cnf /etc/my.cnf
cp: overwrite `/etc/my.cnf'? y
[root@pxc01 pxc]# grep -Ev "^$|^[#;]" /etc/my.cnf
[mysqld]
user=mysql
innodb_buffer_pool_size = 1024M
datadir = /opt/mysql/data
port = 3306
server_id = 105213306
socket = /opt/mysql/mysql.sock
pid-file = /opt/mysql/logs/mysql.pid
log-error = /opt/mysql/logs/error.log
log_warnings = 2
slow_query_log_file = /opt/mysql/logs/slow.log
long_query_time = 0.1
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_cluster_address=gcomm://10.105.2.21,10.105.2.22,10.105.2.23 //集群各节点的ip
binlog_format=ROW //必须是row
default_storage_engine=InnoDB
wsrep_slave_threads= 4 //最好是物理CPUX2
wsrep_log_conflicts
innodb_autoinc_lock_mode=2
wsrep_node_address=10.105.2.21 //本地ip
wsrep_cluster_name=pxc-cluster //自定义集群名字
wsrep_node_name=pxc01 //节点名称
pxc_strict_mode=ENFORCING
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth="sstuser:sstuser" //用于同步数据库的用户

pxc02配置文件
[root@pxc02 etc]# grep -Ev "^$|^[#]" my.cnf
[mysqld]
user=mysql
innodb_buffer_pool_size = 1024M
datadir = /opt/mysql/data
port = 3306
server_id = 105223306
socket = /opt/mysql/mysql.sock
pid-file = /opt/mysql/logs/mysql.pid
log-error = /opt/mysql/logs/error.log
log_warnings = 2
slow_query_log_file = /opt/mysql/logs/slow.log
long_query_time = 0.1
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_cluster_address=gcomm://10.105.2.21,10.105.2.22,10.105.2.23
binlog_format=ROW
default_storage_engine=InnoDB
wsrep_slave_threads= 4
wsrep_log_conflicts
innodb_autoinc_lock_mode=2
wsrep_node_address=10.105.2.22
wsrep_cluster_name=pxc-cluster
wsrep_node_name=pxc02
pxc_strict_mode=ENFORCING
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth="sstuser:sstuser"

pxc03
[root@pxc03 etc]# grep -Ev "^$|^#" my.cnf
[mysqld]
user=mysql
innodb_buffer_pool_size = 1024M
datadir = /opt/mysql/data
port = 3306
server_id = 105233306
socket = /opt/mysql/mysql.sock
pid-file = /opt/mysql/logs/mysql.pid
log-error = /opt/mysql/logs/error.log
log_warnings = 2
slow_query_log_file = /opt/mysql/logs/slow.log
long_query_time = 0.1
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_cluster_address=gcomm://10.105.2.21,10.105.2.22,10.105.2.23
binlog_format=ROW
default_storage_engine=InnoDB
wsrep_slave_threads= 4
wsrep_log_conflicts
innodb_autoinc_lock_mode=2
wsrep_node_address=10.105.2.23
wsrep_cluster_name=pxc-cluster
wsrep_node_name=pxc03
pxc_strict_mode=ENFORCING
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth="sstuser:sstuser"

启动：

systemctl start mysqld && systemctl  enable mysqld

查找默认密码并进行登录

sudo grep 'temporary password' /var/log/mysqld.log

添加同步用户sstuser:sstuser

mysql> alter user 'root'@'localhost' identified by 'helloworld';
Query OK, 0 rows affected (0.01 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)
mysql> create user 'sstuser'@'localhost' identified by 'sstuser';
Query OK, 0 rows affected (0.02 sec)
mysql> grant reload,lock tables,replication client,process on *.* to 'sstuser'@'localhost';
Query OK, 0 rows affected (0.01 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)

分别启动pxc02,pxc03

systemctl start mysqld && systemctl  enable mysqld

部署过程中遇到的问题:

1.安装时候遇到libev.so错误；

解决方法：

yum -y install epel*

yum -y install libdev

[root@pxc03 etc]# /etc/init.d/mysql start

Initializing MySQL database: [ OK ]

Starting MySQL (Percona XtraDB Cluster).....................................The server quit without updating PID file (/opt/mysql/logs/mysql.pid). [FAILED]

MySQL (Percona XtraDB Cluster) server startup failed! [FAILED]

解决方法：检查日志，一般是网络不通，地址写的不对，初始化的时候datadir不是空的文件夹，或者datadir 目录不对；

pxc验证:

在pxc0创建库并插入数据，在pxc02 pxc03查看

mysql> create database pxc01;
Query OK, 1 row affected (0.01 sec)

mysql> use pxc01;
Database changed
mysql> create table t1(id int,name varchar(20),sex char(1));
Query OK, 0 rows affected (0.06 sec)

mysql> insert into t1 values(26,"world","M");
ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on a table (pxc01.t1) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER //验证了PXC的特性，每个表都要有主键
mysql> alter table t1 add primary key (id);
Query OK, 0 rows affected (0.07 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> insert into t1 values(26,"world","M");
Query OK, 1 row affected (0.03 sec)

在pxc02-03查看数据

image.png

然后分别去验证，如果都能写入，在集群各节点都可以查看，日志里没有异常错误，说明PXC 搭建完成；

注：

percona xtradb cluster 初始化时需要将第一个集群节点信息置空，启动后方能启动其他节点。

mariadb galera cluster 初始化则执行galera_new_cluster进行初始化并启动数据库服务。

集群最后一个停止服务节点为下次启动时初始化启动节点。

附：

mariadb galera cluster ：

[galera]

# Mandatory settings
wsrep_on=ON
wsrep_provider=/lib64/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.10.1,192.168.10.2,192.168.10.3
wsrep_node_name=node1
wsrep_node_address=192.168.10.1
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
percona xtradb cluster：

[mysqld]
# Path to Galera library
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
# Cluster connection URL contains IPs of nodes
#If no IP is found, this implies that a new cluster needs to be created,
#in order to do that you need to bootstrap this node
wsrep_cluster_address=gcomm://192.168.10.12,192.168.10.13,192.168.10.14,192.168.10.15,192.168.10.16
#wsrep_cluster_address=gcomm://
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB
# Slave thread to use
wsrep_slave_threads= 8
wsrep_log_conflicts
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node IP address
wsrep_node_address=192.168.10.12
# Cluster name
wsrep_cluster_name=pxc-719
#If wsrep_node_name is not specified, then system hostname will be used
wsrep_node_name=pxc-cluster-node-1
#pxc_strict_mode allowed values: DISABLED,PERMISSIVE,ENFORCING,MASTER
pxc_strict_mode=ENFORCING
# SST method
wsrep_sst_method=xtrabackup-v2
#Authentication for SST method
#wsrep_sst_auth="sstuser:s3cretPass"
wsrep_sst_auth="root:cssl#123"

PXC常用管理 https://www.jianshu.com/p/7ae73a6baf03

PXC原理与启动关闭及注意事项 https://blog.csdn.net/zengxuewen2045/article/details/51834861

比较全的文章： https://blog.csdn.net/zisefeizhu/article/details/81873466

pxc学习时视频 https://www.imooc.com/learn/993

mysql优化：https://blog.csdn.net/qq_26941173/article/details/77823184

mysql的innodb_buffer_pool_size设置：https://www.cnblogs.com/wanbin/p/9530833.html

PXC要注意的问题

1）脑裂：任何命令执行出现unkown command ，表示出现脑裂，集群两节点间4567端口连不通，无法提供对外服务。

   SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";

2）并发写：三个节点的自增起始值为1、2、3，步长都为3，解决了insert问题，但update同时对一行操作就会有问题，出现：

   Error： 1213  SQLSTATE: 40001，所以更新和写入在一个节点上操作。

3）DDL：引起全局锁，采用：pt-online-schema-change

4）MyISAM引擎不能被复制，只支持innodb

5）pxc结构里面必须有主键，如果没有主建，有可能会造成集中每个节点的Data page里的数据不一样

6）不支持表级锁，不支持lock /unlock tables

7）pxc里只能把slow log ,query log 放到File里

8）不支持XA事务

9）性能由集群中性能最差的节点决定

配置文件注意：

wsrep_sst_method：state_snapshot_transfer(SST)使用的传输方法，可用方法有mysqldump、rsync和xtrabackup，前两者在传输时都需要对Donor加全局只读锁(FLUSH TABLES WITH READ LOCK)，xtrabackup则不需要(它使用percona自己提供的backup lock)。强烈建议采用xtrabackup

innodb_autoinc_lock_mode：只能设置为2，设置为0或1时会无法正确处理死锁问题

注意：

集群中最后一个关闭的节点，下次启动时，应该按照主节点启动。如何判断哪个是最后一个关闭的节点呢？ 查看数据目录下 /data/grastate.dat

如果safe_to_bootstrap: 1 表是该节点为最后一个关闭的节点。

所有节点的意外退出

每个节点safe_to_bootstrap都等于0，挑选一个节点将改值设置为1，按照启动主节点的方法启动，其他启动mysql服务即可。

实列：

vim /home/mysql/data/grastate.dat

# GALERA saved state

version: 2.1

uuid: f50e341c-5783-11e9-a3f2-7a3a69888747

seqno: -1

safe_to_bootstrap: 0 ---这里

其他查看：SHOW GLOBAL STATUS LIKE 'wsrep_%';

+----------------------------------+-------------------------------------------------------+

| Variable_name | Value |

+----------------------------------+-------------------------------------------------------+

| wsrep_local_state_uuid | f50e341c-5783-11e9-a3f2-7a3a69888747 |

| wsrep_protocol_version | 9 |

| wsrep_last_applied | 4571127 | --同步应用的次数

| wsrep_last_committed | 4571127 | --表示的是当前节点最新提交的事务号，也是最新galera GTID的后半部分，前半部分是参数wsrep_local_state_uuid的值，在每次执行提交、DDL执行完成或APPLY之后，都会更新这个值

| wsrep_replicated | 282517 | --表示当前节点已经复制过的事务数目

| wsrep_replicated_bytes | 246223616 | --与参数wsrep_replicated相对应，每一个事务的大小不同，这个参数表示已经复制的wsrep_replicated个事务总字节大小（key和data）的总和

| wsrep_repl_keys | 1463026 | --当前节点已经复制的wsrep_replicated个事务对应的总的key的数目，一个事务可以包含多个key

| wsrep_repl_keys_bytes | 18484632 | --与参数wsrep_repl_keys对应，所有发送的key的大小加起来的值，代表总的字节大小

| wsrep_repl_data_bytes | 208613711 | --与参数wsrep_repl_keys_bytes对应，与上面几个参数的关系时：wsrep_replicated_bytes=wsrep_repl_keys_bytes+wsrep_repl_data_bytes+wsrep_replicated*64

| wsrep_repl_other_bytes | 0 |

| wsrep_received | 605577 | --与参数wsrep_replicated对应，表示当前节点已经收到的从写节点复制过的总事务数，单位为事务个数

| wsrep_received_bytes | 519555160 | --对参数wsrep_received对应，表示收到的所有事务包含的key及DATA的字节数，从其他节点结收写入请求数据的总字节数

| wsrep_local_commits | 279602 | --表示当前节点本机提交的事务个数

| wsrep_local_cert_failures | 921 | --表示本地节点验证失败的 次数

| wsrep_local_replays | 0 | --表示本地做replay的次数，这个参数值越大，表示本地出错频率越高

| wsrep_local_send_queue | 0 | --表示当前节点在等待复制的事务个数，就是发送队列的长度；如果该参数值越大，说明本地压力或网络性能有问题，可以作为监控指标

| wsrep_local_send_queue_max | 2 | --当前节点历史上等待队列最大的事务数目

| wsrep_local_send_queue_min | 0 | --当前节点历史上等待列最小的事务数目，一般就是0

| wsrep_local_send_queue_avg | 0.000732 | --当前节点自从上次flush参数之后，等待队列长度的平均值。其值越大则表示压力越大，但是这个参数中没有包括flow_control的等待，X1--这个和X2，说明集群队列积累同步请求太多，应该增加线程处理（其值越大则表示压力越大）

| wsrep_local_recv_queue | 0 | --当前节点从其他节点接受的队列中事务个数，如果这个值达到gcs.fc_limit值的话，就会发生flow control，本节点会向整个集群发送flow control小心，整个集群会被阻塞，二等地wsrep_local_recv_queue的值小于gcs.fc_limit*gcs.fc_factor之后，flow control解除。

| wsrep_local_recv_queue_max | 931 | --表示当前节点历史接收队列中事务的最大个数

| wsrep_local_recv_queue_min | 0 | --当前节点历史接收队列中事务的最小个数

| wsrep_local_recv_queue_avg | 0.730698 | --当前节点历史接收队列中事务的平均个数 X2--这个和X1，说明集群队列积累同步请求太多，应该增加线程处理（如果某个节点的平均值都比其他的大，则可以考虑这个机器的硬件性能是不太好，或压力造成的；）

| wsrep_local_cached_downto | 4442924 | --表示当前节点cache中的最小GTID值，可以决定集群中其他节点在启动时，是需要做IST还是SST

| wsrep_flow_control_paused_ns | 0 | --表示由于flow control消息引起的集群阻塞时间长度，单位是纳秒。这个参数不能通过flush status来重置。它的值是递增累计的

| wsrep_flow_control_paused | 0.000000 | --这个值越接近0，说明系统越正常，如果差不多为1，则说明当前系统基本不能做复制了

| wsrep_flow_control_sent | 0 | --这个值越大表示这个节点做的越慢。如果这个值突增了，则说明这个节点有可能出现了问题，或这个节点负载增大了，导致apply写集变慢；

| wsrep_flow_control_recv | 0 | --当这个参数突增时，就需要查看是哪个节点的sent值突增了，那么这个节点就有可能存在性能问题；

| wsrep_flow_control_interval | [ 173, 173 ] |

| wsrep_flow_control_interval_low | 173 |

| wsrep_flow_control_interval_high | 173 |

| wsrep_flow_control_status | OFF |

| wsrep_cert_deps_distance | 52.184628 | --表示一个事务的GTID2和它所依赖的事务的GTID1之间差值的总和，与这段时间内所做的总的验证通过的事务（n_certified）个数的比值

| wsrep_apply_oooe | 0.037159 | --如果这个值很接近0，则说明这个系统的执行基本是串行的

| wsrep_apply_oool | 0.006556 | --如果值越大，则表示并行执行时乱序的现象越多；如果值越小，则说明基本是顺序执行的；

| wsrep_apply_window | 1.083433 | --这个值越大，表示并行apply事务间的GTID相差越大，这个节点的活动也就越频繁；

| wsrep_commit_oooe | 0.000000 | --这个参数的值永远是0

| wsrep_commit_oool | 0.006517 | --这个参数的值永远是0

| wsrep_commit_window | 1.059816 | --如果越接近1，则说明写入越有秩序，事务压力相对比较均匀，越大则相反

| wsrep_local_state | 4 | --表示当前节点的状态，（有4个值： 1：表示正在请求加入集群，速度很快一般看不到这个状态；2：表示正在同步数据；3：表示当前节点已经加入集群；4：表示当前节点与整个集群是完全相同的）

| wsrep_local_state_comment | Synced | --节点状态

| wsrep_cert_index_size | 151 | --表示当前节点的验证队列中，总共有多少个key

| wsrep_cert_bucket_count | 15184 |

| wsrep_gcache_pool_size | 134219040 |

| wsrep_causal_reads | 0 | --表示的是处理这种写集等待的次数，不过这个参数已经不用了

| wsrep_cert_interval | 0.066156 | --表示的是，所有事务的GTID值与它们各自可以看到的最新提交事务的GTID值之间差值的总和，与这段时间内所做的被验证通过事务的总个数的比值

| wsrep_open_transactions | 0 |

| wsrep_open_connections | 0 |

| wsrep_ist_receive_status | |

| wsrep_ist_receive_seqno_start | 0 |

| wsrep_ist_receive_seqno_current | 0 |

| wsrep_ist_receive_seqno_end | 0 |

| wsrep_incoming_addresses | 192.168.1.91:3307,192.168.1.89:3307,192.168.1.90:3307 | --所有已经加入或正在加入集群的节点信息，可以通过该信息来做监控；

| wsrep_cluster_weight | 3 |

| wsrep_desync_count | 0 | --延时的节点数量

| wsrep_evs_delayed | |

| wsrep_evs_evict_list | |

| wsrep_evs_repl_latency | 0.000368105/0.000633546/0.000978417/0.000119225/85 | --表示GCOMM在消息传送时的复制延迟，单位是秒；采样时间通过参数evs.stats_report_period来控制，默认是PT1M

| wsrep_evs_state | OPERATIONAL |

| wsrep_gcomm_uuid | 51274217-5f27-11e9-87e9-03d972a6c506 |

| wsrep_cluster_conf_id | 25 | --正常情况下所有节点上该值是一样的.如果值不同,说明该节点被临时"分区"了.当节点之间网络连接恢复的时候应该会恢复一样的值

| wsrep_cluster_size | 3 | --表示当前集群中节点的个数，与参数wsrep_incoming_addresses对应，也可以作为监控项，一般监控条件必须大于或等于3，如果是3的话，则会发生脑裂的问题

| wsrep_cluster_state_uuid | f50e341c-5783-11e9-a3f2-7a3a69888747 | --在集群所有节点的值应该是相同的,有不同值的节点,说明其没有连接入集群

| wsrep_cluster_status | Primary | --集群组成的状态.如果不为"Primary",说明出现"分区"或是"split-brain"状况，属于不正常的状态

| wsrep_connected | ON | --如果该值为Off,且wsrep_ready的值也为Off,则说明该节点没有连接到集群.(可能是wsrep_cluster_address或wsrep_cluster_name等配置错造成的.具体错误需要查看错误日志)

| wsrep_local_bf_aborts | 501 | --表示当前节点在运行过程中，由于事务的冲突，导致本地事务被主动取消的事务个数。如果这个值比较大，说明集群的写入冲突比较多，可能需要调整写入的方式，比如切换写节点等

| wsrep_local_index | 1 | --表示当前节点在集群中的编号。在集群中，每个节点都有一个唯一的编号，从0开始计数

| wsrep_provider_name | Galera |

| wsrep_provider_vendor | Codership Oy <info@codership.com> |

| wsrep_provider_version | 3.35(rddf9876) |

| wsrep_ready | ON | --如下解释

+----------------------------------+-------------------------------------------------------+

wsrep_ready ：

正常情况下为ON，如果变为OFF，则可能是发生了脑裂，或者和其他节点之间的网络连不上，

又或者是galera集群没有正常启动等；一般可以通过命令set global wsrep_provider_options='pc.bootstrap=yes' 来恢复，

不过在执行这个命令之后，需要观察整个集群的状态，不然可能会导致这个节点在逻辑上脱离集群。

这个命令的作用就是让当前节点变为primary，如果执行了，则说明确定要使用这个节点来提供服务了；

................注意下面几个察看命令...............

如果配置了指向集群地址，参数值，应该是你指定集群的IP地址

mysql> SHOW VARIABLES LIKE 'wsrep_cluster_address';

此参数查看是否开启

mysql> show status like 'wsrep_ready';

查看集群的成员数

mysql> show status like 'wsrep_cluster_size';

这个查看wsrep的相关参数

mysql> show status like 'wsrep%';

状态信息

show status like "%wsrep%"; # 查看集群所有信息

流量控制

如果同步队列太大，就会进行流量控制，控制写入速度。例如在集群中添加了一个新节点，该节点中并没有数据。该节点就会对其他节点发出全量同步请求，请求数据量过大，就会发生流量控制。

wsrep_follow_control_paused 流控暂停时间占比（0-1）

wsrep_follow_control_send 发送的流控暂停事件的数量 （本节点引发）

wsrep_follow_control_recv 结收的流控暂停事件的数量

wsrep_follow_control_interval 同步队列的上下限，超过上限引发流控

wsrep_follow_control_status 流控状态 off关闭 on开启

解决流控：

解决带宽、增加线程（配置文件中）、更换性能更好的硬件

节点状态

OPEN : 节点启动成功

PRIMARY : 节点成功加入集群

JONNER: 节点同步数据

JONNED: 节点同步数据成功

SYNCED: 该节点可以对外同步读写数据

DONNER: 有节点对改节点进行全量同步

集群的状态

PRIMARY: 正常状态

NON-PRIMARY: 脑裂状态

DISCONNECTED：断开连接状态

脑裂（建议采用奇数的集群，偶数的集群容易脑裂）

数据没有同步成功，造成两个节点数据不一致称之为脑裂状态。

PXC方案：如果一个节点能够连接的其他节点数量不足半数，断开该节点。能够连接其他节点的数量超过半数的这些节点组成一个集群，此时处于NON-PRIMARY 状态还能够对外提供读写服务。

集群与节点相关信息

wsrep_local_state_comment 节点状态

wsrep_cluster_status 集群状态

wsrep_connected 节点是否连接到集群

wsrep_ready 集群是否正常工作

wsrep_cluster_size 节点数量

wsrep_desync_count 延时节点数量

wsrep_incomming_address 节点的IP地址

事务相关信息

wsrep_cert_deps_distance 事务执行并发数

wsrep_apply_oooe 结收队列中事务占比

wsrep_apply_oool 结收队列中事务乱序执行频率

wsrep_apply_window 结收队列中事务的平均数量

wsrep_commit_oooe 发送队列中事务占比

wsrep_commit_oool 发送队列中事务乱序执行频率 （不存在没意义）

wsrep_commit_window 发送队列中事务的平均数量

Galera---> PXC or MGC部署

Percona XtraDB Cluster5.7部署

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读