原创

Galera Cluster for MySQL 详解(二)——安装配置

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://wxy0327.blog.csdn.net/article/details/102607193

目录

一、Galera集群实验环境

二、初始安装

1. 安装galera-3、mysql-wsrep-5.7、Percona-XtraBackup-2.4.15

2. 修改配置文件

3. 初始化集群

4. 启动集群其它节点的mysqld服务

5. 验证安装

6. 问题排查

三、使用SST增加节点

四、使用IST增加节点

1. 设置gcache.size

2. IST测试

参考:


一、Galera集群实验环境

        本篇以搭建三节点Galera Cluster for MySQL 5.7为例,说明Galera集群的安装步骤与基本配置,实验环境如下。

        IP与主机名:
172.16.1.125    hdp2
172.16.1.126    hdp3
172.16.1.127    hdp4

        软件环境:
CentOS Linux release 7.2.1511 (Core)
galera-3.28
mysql-wsrep-5.7.27
Percona-XtraBackup-2.4.15

        硬件环境:
三台虚拟机,每台基本配置为:
. 双核双CPU,Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
. 8G物理内存,8G Swap
. 100G物理硬盘

二、初始安装

        我们从最简单的场景开始,假设在没有任何应用数据和访问的情况下,从头开始安装Galera集群。

1. 安装galera-3、mysql-wsrep-5.7、Percona-XtraBackup-2.4.15

        以下步骤以root用户在三台主机执行。

(1)安装依赖包

yum install perl-Time-HiRes
yum -y install perl-DBD-MySQL.x86_64
yum -y install libaio*

(2)创建yum源文件

cat > /etc/yum.repos.d/galera.repo <<-END
[galera]
name = Galera
baseurl = https://releases.galeracluster.com/galera-3.28/centos/7/x86_64
gpgkey = https://releases.galeracluster.com/galera-3.28/GPG-KEY-galeracluster.com
gpgcheck = 1

[mysql-wsrep]
name = MySQL-wsrep
baseurl =  https://releases.galeracluster.com/mysql-wsrep-5.7.27-25.19/centos/7/x86_64
gpgkey = https://releases.galeracluster.com/mysql-wsrep-5.7.27-25.19/GPG-KEY-galeracluster.com
gpgcheck = 1
END

(3)安装galera-3与mysql-wsrep-5.7

yum install -y galera-3 mysql-wsrep-5.7

(4)确认相关的rpm包

[root@hdp2~]#rpm -qa | grep -E 'galera|wsrep'
mysql-wsrep-client-5.7-5.7.27-25.19.el7.x86_64
galera-3-25.3.28-1.el7.x86_64
mysql-wsrep-common-5.7-5.7.27-25.19.el7.x86_64
mysql-wsrep-libs-5.7-5.7.27-25.19.el7.x86_64
mysql-wsrep-server-5.7-5.7.27-25.19.el7.x86_64
mysql-wsrep-5.7-5.7.27-25.19.el7.x86_64
mysql-wsrep-libs-compat-5.7-5.7.27-25.19.el7.x86_64
[root@hdp2~]#

(5)安装xtrabackup
        如果SST使用xtrabackup需要执行此步骤。注意xtrabackup与MySQL服务器的兼容性,如果版本不匹配会在xtrabackup的日志中报类似下面的错误:

innobackupex: Error: Unsupported server version: '5.7.27' Please report a bug at https://bugs.launchpad.net/percona-xtrabackup

对于MySQL 5.7.27,可从https://www.percona.com/downloads/Percona-XtraBackup-2.4/LATEST/下载xtrabackup 2.4.15版本。

# 安装xtrabackup
rpm -ivh percona-xtrabackup-24-2.4.15-1.el7.x86_64.rpm

        至此软件包安装已完成。启动集群只要很少几项必须配置。

2. 修改配置文件

        编辑/etc/my.cnf文件,增加以下内容:

[mysqld]
log-error=/var/log/mysqld.log
wsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
wsrep_cluster_name="mysql_galera_cluster"
wsrep_cluster_address="gcomm://172.16.1.125,172.16.1.126,172.16.1.127"
wsrep_sst_method=xtrabackup
wsrep_sst_auth=root:P@sswo2d
wsrep_node_name=node1               # 另外两个节点分别为node2、node3
wsrep_node_address="172.16.1.125"   # 另外两个节点分别为172.16.1.126、172.16.1.127

        系统变量说明:

  • log-error:MySQL错误日志文件,集群初始化后从该文件中查找初始密码。
  • wsrep_provider:galera库文件。
  • wsrep_cluster_name:集群名称。
  • wsrep_cluster_address:集群节点IP地址。
  • wsrep_sst_method:SST方法。
  • wsrep_sst_auth:SST认证信息,xtrabackup使用此用户名和口令连接数据库实例。
  • wsrep_node_name:当前节点名称。
  • wsrep_node_address:当前节点地址。

3. 初始化集群

        下面步骤以root用户在任一主机执行。

(1)启动第一个节点

/usr/bin/mysqld_bootstrap

        该命令会启动本机的 mysqld 服务,MySQL缺省安装目录为/var/lib/mysql。注意,/usr/bin/mysqld_bootstrap 命令只在集群第一个节点启动时使用,因为该脚本中带有一个参数:–wsrep-new-cluster,代表新建集群。

# 查看mysqld服务状态
systemctl status mysqld

(2)查找并修改初始密码

# 查找初始密码
grep -i 'temporary password' /var/log/mysqld.log

# 修改mysql root用户密码,需要根据提示输入上一步输出的初始密码
mysqladmin -uroot -p password 'P@sswo2d'

(3)创建一个非root管理账号

create user wxy identified by 'P@sswo2d';
grant all on *.* to wxy with grant option;

4. 启动集群其它节点的mysqld服务

# 在其它两个主机上以root用户执行

systemctl start mysqld

5. 验证安装

(1)查看集群节点数量

mysql> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.00 sec)

(2)在三个节点分别建表插入数据,查看复制情况

-- node1
create database test;
use test;
create table t1(a int);
insert into t1 values(1);

-- node2
use test;
create table t2(a int);
insert into t2 values(2);

-- node2
use test;
create table t3(a int);
insert into t3 values(3);

        在三个节点查询数据,结果一致:

mysql> select t1.a,t2.a,t3.a from test.t1,test.t2,test.t3;
+------+------+------+
| a    | a    | a    |
+------+------+------+
|    1 |    2 |    3 |
+------+------+------+
1 row in set (0.00 sec)

6. 问题排查

        如果在初始化集群或启动mysqld服务时,错误日志中出现类似以下错误:

2019-10-05T10:25:29.729981Z 0 [ERROR] WSREP: wsrep_load(): dlopen(): /usr/lib64/galera-3/libgalera_smm.so: symbol SSL_COMP_free_compression_methods, version libssl.so.10 not defined in file libssl.so.10 with link time reference

说明galera插件没有加载成功。此时mysqld仍然可以成功启动,但是以单实例提供读写服务,不会进行节点间数据复制。升级OpenSSL软件包即可解决此问题。例如:

cd /etc/yum.repos.d/
wget http://mirrors.163.com/.help/CentOS7-Base-163.repo
yum -y upgrade openssl

三、使用SST增加节点

        假设node1、node2是正在使用的Galera集群节点,现在要增加第三个节点node3。目标是在对现有节点无阻塞的前提下,为新增节点进行SST数据同步。

(1)将hdp4初始化为新节点

# 在hdp4上执行
systemctl stop mysqld
rm -rf /var/lib/mysql
rm -rf /var/log/mysqld.log

(2)使用tpcc-mysql对hdp2执行压测,模拟应用负载

# 安装tpcc-mysql
tar -zxvf tpcc-mysql.tar.gz
cd tpcc-mysql/src
make
cd ..

# 创建压测库表
mysql -uwxy -pP@sswo2d -h172.16.1.125 -e "create database tpcc_test;"
mysql -uwxy -pP@sswo2d -h172.16.1.125 -Dtpcc_test < create_table.sql
mysql -uwxy -pP@sswo2d -h172.16.1.125 -Dtpcc_test < add_fkey_idx.sql

# 准备数据
tpcc_load 172.16.1.125 tpcc_test wxy P@sswo2d 10

# 备份测试库用于重复测试
mysqldump --databases tpcc_test -uwxy -pP@sswo2d -h172.16.1.125 > tpcc_test.sql

# 执行压测
tpcc_start -h172.16.1.125 -d tpcc_test -u wxy -p "P@sswo2d" -w 10 -c 32 -r 60 -l 300

        关于tpcc-mysql的详细安装及使用说明参见https://wxy0327.blog.csdn.net/article/details/94614149#1.%20%E6%B5%8B%E8%AF%95%E8%A7%84%E5%88%92

(3)在压测执行期间,启动hdp4上的MySQL实例

systemctl start mysqld

        在hdp4启动过程中,hdp2、hdp3都是非阻塞的,但是会报以下锁错误:

Deadlock found when trying to get lock; try restarting transaction
Lock wait timeout exceeded; try restarting transaction

        生产系统的Galera集群中联机添加节点时需要关注这个问题。当hdp4的MySQL实例启动成功,后续的压测过程不会再报错。hdp2的/var/log/mysqld.log文件中有以下关于SST的信息:

2019-10-16T02:04:07.877299Z 2 [Note] WSREP: Assign initial position for certification: 106026, protocol version: 4
2019-10-16T02:04:07.877385Z 0 [Note] WSREP: Service thread queue flushed.
2019-10-16T02:04:08.307002Z 0 [Note] WSREP: Member 0.0 (node3) requested state transfer from '*any*'. Selected 1.0 (node1)(SYNCED) as donor.
2019-10-16T02:04:08.307028Z 0 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 106177)
2019-10-16T02:04:08.377506Z 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2019-10-16T02:04:08.377644Z 0 [Note] WSREP: Running: 'wsrep_sst_xtrabackup --role 'donor' --address '172.16.1.127:4444/xtrabackup_sst' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'cada8d04-ef2b-11e9-a196-1ea90518b418:106177''
2019-10-16T02:04:08.380201Z 2 [Note] WSREP: sst_donor_thread signaled with 0
WSREP_SST: [INFO] Streaming with tar (20191016 10:04:08.542)
WSREP_SST: [INFO] Using socat as streamer (20191016 10:04:08.544)
WSREP_SST: [INFO] Streaming the backup to joiner at 172.16.1.127 4444 (20191016 10:04:08.552)
WSREP_SST: [INFO] Evaluating innobackupex --defaults-file=/etc/my.cnf $INNOEXTRA --galera-info --stream=$sfmt ${TMPDIR} 2>${DATA}/innobackup.backup.log | socat -u stdio TCP:172.16.1.127:4444; RC=( ${PIPESTATUS[@]} ) (20191016 10:04:08.555)
2019-10-16T02:04:10.586433Z 0 [Note] WSREP: (cad9d0f0, 'tcp://0.0.0.0:4567') turning message relay requesting off
2019-10-16T02:05:11.408356Z 89 [Note] WSREP: Provider paused at cada8d04-ef2b-11e9-a196-1ea90518b418:108094 (111402)
2019-10-16T02:05:11.679454Z 89 [Note] WSREP: resuming provider at 111402
2019-10-16T02:05:11.679485Z 89 [Note] WSREP: Provider resumed.
2019-10-16T02:05:12.057568Z 0 [Note] WSREP: 1.0 (node1): State transfer to 0.0 (node3) complete.
2019-10-16T02:05:12.057596Z 0 [Note] WSREP: Shifting DONOR/DESYNCED -> JOINED (TO: 108185)
WSREP_SST: [INFO] Total time on donor: 0 seconds (20191016 10:05:12.057)
2019-10-16T02:05:12.058281Z 0 [Note] WSREP: Member 1.0 (node1) synced with group.
2019-10-16T02:05:12.058296Z 0 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 108185)
2019-10-16T02:05:12.127179Z 2 [Note] WSREP: Synchronized with group, ready for connections
2019-10-16T02:05:12.127215Z 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2019-10-16T02:05:20.968604Z 0 [Note] WSREP: 0.0 (node3): State transfer from 1.0 (node1) complete.
2019-10-16T02:09:34.556227Z 0 [Note] WSREP: Member 0.0 (node3) synced with group.

        当在hdp4上执行systemctl start mysqld后,集群中的所有节点首先会将已提交的事务刷新到磁盘,之后选择一个捐赠者向新增节点全量同步数据,本例中系统选择了node1作为捐献者。然后node1调用xtrabackup向node3拷贝物理文件,期间产生的写集将被缓存。node1成为捐献者时,状态由SYNCED转为DONOR/DESYNCED;当xtrabackup备份完成时,其状态变为JOINED;最后应用完缓存的写集时,状态又从JOINED变为SYNCED。同样从hdp4的/var/log/mysqld.log文件中可以发现,node3的状态变化过程为:OPEN -> PRIMARY -> JOINER -> JOINED -> SYNCED。

四、使用IST增加节点

        SST方法将全量数据从捐献者节点拷贝到新加入节点,这类似于在MySQL主库做一个全备份,然后在从库还原,只不过在Galera集群中,该过程依赖于新加入节点的状态而自动触发。对于高并发大库环境下新增节点,SST方式可能会很痛苦。首先,如果使用mysqldump或rsync做SST,捐赠者节点时被阻塞的。其次,对于几百GB或更多的数据集,即使网络够快,同步过程也需要几个小时才能完成。所以生产环境新增节点时最好避免使用SST,而是改用IST。

        IST只向新节点发送它比捐赠者Gcache中少的写集。Gcache是Galera节点保存写集副本的文件。IST比SST快得多,无阻塞,对捐赠者无明显影响。只要可能,这应该是新增节点的首选方案。

        有时SST是不可避免的,当Galera无法确定新增节点状态时会发生这种情况。状态存储在grastate.dat文件中,如果发生以下情况将触发SST:

  • 在MySQL数据目录下不存在grastate.dat文件——节点可能是一个“干净的”新节点。
  • grastate.dat文件中没有seqno或group id——节点可能在DDL期间崩溃。
  • 由于缺少权限或文件系统损坏,grastate.dat无法读取。

1. 设置gcache.size

        在上篇介绍IST时曾经提到,使用IST需要满足两个先决条件:新节点UUID与集群相同;Gcache足够存储增量写集。第一点很好满足,用xtrabackup对集群实例做物理备份时会自动为新节点保持集群的UUID。要满足第二个条件,需要进行一些计算,估计所需Gcache的大小。例如,对于tpcc-mysql压测,可以按下面的方法估算。

(1)执行压测

tpcc_start -h172.16.1.125 -d tpcc_test -u wxy -p "P@sswo2d" -w 10 -c 32 -r 60 -l 300

(2)在压测期间执行查询
 

set global show_compatibility_56=on;
set @start := (select sum(variable_value/1024/1024) from information_schema.global_status where variable_name like 'wsrep%bytes'); 
do sleep(60); 
set @end := (select sum(variable_value/1024/1024) from information_schema.global_status where variable_name like 'wsrep%bytes'); 
select round((@end - @start),2) as `Mb/min`, round((@end - @start),2) * 60 as `Mb/hour`;

        该查询计算每分钟写的字节数,结果如下:

+--------+---------+
| Mb/min | Mb/hour |
+--------+---------+
| 116.66 | 6999.60 |
+--------+---------+

        压测总执行时间6分钟(预热1分钟,执行5分钟),gcache.size只要设置为大于117 * 6MB即可,因此这里把gcache.size均设置为1G,足够演示IST数据同步。在三个节点的配置文件/etc/my.cnf中添加如下参数,然后重启实例使之生效。

wsrep_provider_options="gcache.size=1073741824"

2. IST测试

        同样假设node1、node2是正在使用的Galera集群节点,现在要增加第三个节点node3。为避免SST,将从node1使用xtrabackup创建完整备份,在node3上恢复备份并创建Galera状态文件,以便Galera可以确定节点的状态并跳过SST。为了尽可能接近IST之前的最新数据,还将创建一个增量备份。

(1)将hdp4初始化为新节点

# 在hdp4上用root用户执行
systemctl stop mysqld
rm -rf /var/lib/mysql/*
rm -rf /var/log/mysqld.log 
rm -rf /tmp/incremental/*

(2)向集群重新导入压测库

mysql -uwxy -pP@sswo2d -h172.16.1.125 -Dtpcc_test < tpcc_test.sql

(3)执行压测模拟生产负载

tpcc_start -h172.16.1.125 -d tpcc_test -u wxy -p "P@sswo2d" -w 10 -c 32 -r 60 -l 300

        接下来的第(4)、(5)、(6)、(7)步骤均在第(3)步运行期间执行。

(4)手工执行对集群的xtrabackup备份

# 在hdp2上用mysql用户执行下面的命令进行全量备份(已经事先配置好了hdp2到hdp4的免密登录)
innobackupex --defaults-file=/etc/my.cnf --user=wxy --password=P@sswo2d --socket=/var/lib/mysql/mysql.sock --galera-info --no-lock --stream=xbstream ./ | ssh mysql@172.16.1.127 "xbstream -x -C /var/lib/mysql"

# 再执行一个增量备份,这里仅用于演示
scp mysql@172.16.1.127:/var/lib/mysql/xtrabackup_checkpoints /home/mysql/
innobackupex --defaults-file=/etc/my.cnf --user=wxy --password=P@sswo2d --socket=/var/lib/mysql/mysql.sock --incremental --incremental-basedir=/home/mysql --galera-info --no-lock --stream=xbstream ./ | ssh mysql@172.16.1.127 "xbstream -x -C /tmp/incremental"

(5)恢复hdp4的数据文件
        第(4)步执行完成后,在hdp4上用mysql用户执行以下命令:

# 恢复全量
innobackupex --apply-log --redo-only /var/lib/mysql/
# 恢复增量
innobackupex --apply-log --redo-only /var/lib/mysql/ --incremental-dir=/tmp/incremental

(6)生成grastate.dat文件
        根据xtrabackup_galera_info文件中的内容生成grastate.dat文件,用于IST增量同步。在hdp4上用mysql用户执行以下命令:

# 查看xtrabackup_galera_info
cat /var/lib/mysql/xtrabackup_galera_info

# 生成grastate.dat文件,uuid和seqno的值来自xtrabackup_galera_info
tee /var/lib/mysql/grastate.dat <<EOF
# GALERA saved state
version: 2.1
uuid:    650c3acb-eff8-11e9-9905-c73959fd46ca
seqno:   743544
safe_to_bootstrap: 0
EOF

(7)启动新节点实例

# 用root用户在hdp4上执行
systemctl start mysqld

        hdp2的/var/log/mysqld.log文件中有以下关于IST的信息:

2019-10-17T06:37:00.517675Z 1 [Note] WSREP: Assign initial position for certification: 758430, protocol version: 4
2019-10-17T06:37:00.517777Z 0 [Note] WSREP: Service thread queue flushed.
2019-10-17T06:37:00.961803Z 0 [Note] WSREP: Member 2.0 (node3) requested state transfer from '*any*'. Selected 1.0 (node2)(SYNCED) as donor.
2019-10-17T06:37:01.223935Z 0 [Note] WSREP: 1.0 (node2): State transfer to 2.0 (node3) complete.
2019-10-17T06:37:01.224331Z 0 [Note] WSREP: Member 1.0 (node2) synced with group.
2019-10-17T06:37:02.301018Z 0 [Note] WSREP: (4ce6e1a5, 'tcp://0.0.0.0:4567') turning message relay requesting off
2019-10-17T06:38:14.740957Z 0 [Note] WSREP: 2.0 (node3): State transfer from 1.0 (node2) complete.
2019-10-17T06:39:31.183193Z 0 [Note] WSREP: Member 2.0 (node3) synced with group.

        可以看到,系统选择node2作为捐赠者,它的/var/log/mysqld.log文件中有以下关于IST的信息:

2019-10-17T06:37:00.991588Z 0 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 758624)
2019-10-17T06:37:01.045666Z 2 [Note] WSREP: IST request: 650c3acb-eff8-11e9-9905-c73959fd46ca:743544-758430|tcp://172.16.1.127:4568
2019-10-17T06:37:01.045701Z 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2019-10-17T06:37:01.045885Z 0 [Note] WSREP: Running: 'wsrep_sst_xtrabackup --role 'donor' --address '172.16.1.127:4444/xtrabackup_sst' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid '650c3acb-eff8-11e9-9905-c73959fd46ca:743544' --bypass'
2019-10-17T06:37:01.046440Z 2 [Note] WSREP: sst_donor_thread signaled with 0
2019-10-17T06:37:01.048205Z 0 [Note] WSREP: async IST sender starting to serve tcp://172.16.1.127:4568 sending 743545-758430

显示由hdp3向hdp4发送743545-758430之间的写集。

        可以在hdp4的/var/log/mysqld.log文件中找到node3的IST增量同步和状态变化过程:

2019-10-17T06:37:01.445113Z 0 [Note] WSREP: Signalling provider to continue.
2019-10-17T06:37:01.445151Z 0 [Note] WSREP: Initialized wsrep sidno 2
2019-10-17T06:37:01.445185Z 0 [Note] WSREP: SST received: 650c3acb-eff8-11e9-9905-c73959fd46ca:743544
2019-10-17T06:37:01.445588Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.27'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server - (GPL), wsrep_25.19
2019-10-17T06:37:01.446278Z 2 [Note] WSREP: Receiving IST: 14886 writesets, seqnos 743544-758430
2019-10-17T06:37:01.446519Z 0 [Note] WSREP: Receiving IST...  0.0% (    0/14886 events) complete.
2019-10-17T06:37:02.539991Z 0 [Note] WSREP: (852308ca, 'tcp://0.0.0.0:4567') turning message relay requesting off
2019-10-17T06:37:11.453604Z 0 [Note] WSREP: Receiving IST... 11.1% ( 1648/14886 events) complete.
2019-10-17T06:37:21.485718Z 0 [Note] WSREP: Receiving IST... 23.5% ( 3504/14886 events) complete.
2019-10-17T06:37:31.686873Z 0 [Note] WSREP: Receiving IST... 37.8% ( 5632/14886 events) complete.
2019-10-17T06:37:31.751232Z 24 [Note] Got an error writing communication packets
2019-10-17T06:37:41.721891Z 0 [Note] WSREP: Receiving IST... 56.2% ( 8368/14886 events) complete.
2019-10-17T06:37:51.733818Z 0 [Note] WSREP: Receiving IST... 67.3% (10016/14886 events) complete.
2019-10-17T06:37:54.160644Z 39 [Note] Got an error writing communication packets
2019-10-17T06:38:01.739171Z 0 [Note] WSREP: Receiving IST... 80.0% (11904/14886 events) complete.
2019-10-17T06:38:03.165189Z 45 [Note] Got an error reading communication packets
2019-10-17T06:38:11.778534Z 0 [Note] WSREP: Receiving IST... 94.9% (14128/14886 events) complete.
2019-10-17T06:38:14.765552Z 0 [Note] WSREP: Receiving IST...100.0% (14886/14886 events) complete.
2019-10-17T06:38:14.765871Z 2 [Note] WSREP: IST received: 650c3acb-eff8-11e9-9905-c73959fd46ca:758430
2019-10-17T06:38:14.766840Z 0 [Note] WSREP: 2.0 (node3): State transfer from 1.0 (node2) complete.
2019-10-17T06:38:14.766873Z 0 [Note] WSREP: Shifting JOINER -> JOINED (TO: 777023)
2019-10-17T06:39:31.208799Z 0 [Note] WSREP: Member 2.0 (node3) synced with group.
2019-10-17T06:39:31.208825Z 0 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 777023)
2019-10-17T06:39:31.241137Z 2 [Note] WSREP: Synchronized with group, ready for connections
2019-10-17T06:39:31.241155Z 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.

参考:

文章最后发布于: 2019-10-17 15:24:47
展开阅读全文
0 个人打赏
私信求帮助

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览