原理
复制原理
- mster的I/O线程会将DML等语句写入binlog中。
- slave的I/O线程会请求master的log dump线程，将读取到的binlog的文件名和位置记录到master-info文件中，以便下次向master直接要该位置后的数据，并将binlog写入relay log。
- slave的SQL线程会定时检查relay log，完成更新。
复制技术
-
异步复制
master提交事务后，通知dump线程将bonlog发送slave的I/O线程，然后master就继续处理事务，不等待slvaer服务器同步是否完成。 -
半同步复制
master提交事务后，通知dump线程将bonlog发送slave的I/O线程，至少一个slave将binlog写入到relay log后，mater才能继续处理事务。相当于给一个slave同步，其他slave异步。 -
同步复制
master提交事务后，通知dump线程将bonlog发送slave的I/O线程，当所有从库都同步完成该事务后，mater才能继续处理事务。
复制中，异步master不用等待slave同步反馈，所以性能最高，但可靠性最低；同步master必须等待全部slave同步反馈，所以性能最低，但可靠性最高；而半同步，在数据安全上我们确认slave至少有一台同步完成，在速度方面也是折中，所以性能和可靠都居中。
事务安全保证
主服务器在提交事务时，为保证数据可靠性都应该立即从内寸写入到磁盘上，即便不写入数据文件，也应该写入事务日志中。由于二进制日志为了加速写操作，同样存在内存缓冲区，某些二进制事件可能由于宕机导致缓冲区中事件丢失。
针对上述问题，如下解决：
master节点参数：
sync_binlog=on #当事务提交，将binlog缓冲区中的事件立即刷到磁盘上二进制文件中去，但增加io，严重影响性能
innodb_flush_logs_at_trx_commit=on #在事务提交时，要将内存中跟事务相关的内容写入到事务日志中去。适用innodb引擎
innodb_support_xa=on #
slave节点参数：
skip_slave_start #slave服务器重启后开机自动启动复制线程
sync_master_info = 1 #从服务器从主服务器dump数据后，内存中的数据是否立即同步更新master.info文件
sync_relay_log = 1 #slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay log中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量I/O。
sync_relay_log_info = 1 #，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay-log.info里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量I/O。
配置
配置过程
master：
- 启用binlog
- 配置server-id
- 创建slave账号
slave：
- 启用relay log
- 配置server-id
- 使用slave账号
同步过滤
两种方法：
- master
#只使适用于InnoDB DML
binlog_do_db= # 数据库白名单，会写入binlog
binlog_ignore_db= # 数据库黑名单，不会写入binlog
- slave
#只使适用于InnoDB DML
Replicate_Do_DB= # 复制DB白名单
Replicate_Ignore_DB= # 复制DB黑名单
#同时使用InnoDB和MyISAM存储引擎的表，仅适用于DML和DDL
Replicate_Do_Table= # 复制Table白名单
Replicate_Ignore_Table= # 复制Table黑名单
#只使适用于InnoDB DML
Replicate_Wild_Do_Table= # 复制Table白名单，支持通配符
Replicate_Wild_Ignore_Table= # 复制Table黑名单，支持通配符
相关文件
#slave
master.info #记录slave和master的连接信息
relay-log.info #保存复制的binlog和本地的relay log的对应关系
如果在slvae的配置文件加上下面两个选项，则信息记录到表中去非文件
master-info-repository=table
relay-log-info-repository=table
监控维护
- 复制监控
#master
show master status
show binlog events
show binary logs
#slave
show slaver status
- 清理日志
#bin-log
purge binary logs to 'binlog_file'
purge binary logs before 'datetime'
expire_logs_days=n #自动清理
#relay-log
relay_log_purge=on #自动清理
实验
实验环境
- 服务器，两主两从
10.10.10.10 master_1
10.10.10.11 master_2
10.10.10.20 slaver_1
10.10.10.21 slaver_2
M-S
- 添加配置
#master_1
[mysqld]
server-id=10
log-bin=/var/lib/mysql/master_1_bin
expire_logs_days=10
binlog_do_db=cr
binlog_ignore_db=mysql
#slavr_1
server-id=20
relay-log=/var/lib/mysql/slaver_1_relay
read-only=on
- 创建授权账号
#start master_1
[root@master_1 ~]# systemctl start mariadb
#master_1
MariaDB [(none)]> grant replication slave,replication client on *.* to "slave"@"10.10.10.%" identified by "123";
MariaDB [(none)]> flush privileges;
- 使用授权账号
#start slaver_1
[root@slaver_1 ~]# systemctl start mariadb
#配置slvaer_1
change master to master_host='master_1',master_user='slave',master_password='123',master_log_file='master_1_bin.000002', master_log_pos=647;
#启动slaver_1
MariaDB [(none)]> start slave
- 主从确认
#slaver_1
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
- 其他说明
如果主服务器事前运行一段时间有大量数据，这里我们可以使用mysqldump导入slaver，利用master-data=1选项获取binlog文件和位置，如下语句：
CHANGE MASTER TO MASTER_LOG_FILE='master_1_bin.000002', MASTER_LOG_POS=740;
[root@master_2 ~]# echo "set sql_log_bin=off;source /root/b.sql;change master to master_host='master_1',master_user='master_2',master_password='123'" | mysql -uroot -p
MariaDB [(none)]> change master to master_host='master_1',master_user='master_2',master_password='123';
MariaDB [(none)]> start slave;
M-M
- 添加配置
#master_1
[mysqld]
server-id=10
log-bin=/var/lib/mysql/master_1_bin
expire_logs_days=10
binlog_do_db=cr
binlog_ignore_db=mysql
relay-log=/var/lib/mysql/relay_1_relay
log-slave-updates=1
#master_2
server-id=20
log-bin=/var/lib/mysql/master_2_bin
expire_logs_days=10
binlog_do_db=cr
binlog_ignore_db=mysql
relay-log=/var/lib/mysql/master_2_relay
log-slave-updates=1
- 创建授权账号
#master_1
[root@master_1 ~]# systemctl start mariadb
MariaDB [(none)]> grant replication slave,replication client on *.* to "master_2"@"10.10.10.%" identified by "123";
MariaDB [(none)]> flush privileges;
#master_2
[root@master_2 ~]# systemctl start mariadb
MariaDB [(none)]> grant replication slave,replication client on *.* to "master_1"@"10.10.10.%" identified by "123";
MariaDB [(none)]> flush privileges;
- 使用授权账号
#master_1
[root@slaver_1 ~]# systemctl start mariadb
change master to master_host='master_1',master_user='master_2',master_password='123';
MariaDB [(none)]> start slave
#master_2
[root@slaver_1 ~]# systemctl start mariadb
change master to master_host='master_2',master_user='master_1',master_password='123';
MariaDB [(none)]> start slave
- 主从确认
#master_1
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
#master_2
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
GTID
GTID
- mysql的GTID
GTID=server_uuid:transaction_id
server_uuid: #mysql实例唯一标识
transaction_id: #已提交的事务数量，递增
- mariadb的GTID
GTID=domain ID:server ID:Sequence Number
domain ID: #域id
server ID: #服务id
Sequence Number: #序列号
GTID好处
- 易于更改从服务器连接其他主服务器并从其复制
从服务器记录从旧主服务器的最后一个时间组的全局事务ID。由于全局事物ID在整个复制组中已知，因此从服务器知道在新主服务器何处恢复复制。使用旧式复制，从服务器只知道住服务器最后一次binlog的名字和偏移量，是没有办法确定在新主服务器何处开始复制。 - 以碰撞安全方式记录从站状态
从服务器全局变量gtid_slave_pos记录当前位置。主服务器传送过来的binlog中包含gtid_slave_pos和日志内容，即从服务器复制状态信息和数据信息是在同一事物中完成，这使状态崩溃安全。旧式复制，将状态信息记录在relay-log.info中，与数据相互独立，如果从服务器崩溃，状态信息和数据信息容易失去同步。
domain ID
-
据我理解类似与ospf设置区域。
-
适用于多源复制、多主环形拓扑或手动更新。可能会发生这种情况，多主之间未相互同步状态，导致从服务器与多个主服务器的binlog顺序不同，使用单个GTID是无法完全记录当前状态。
-
域ID是GTID的第一个组件，用于处理此问题。
-
二进制日志从多个主服务器过来，组成多个不同的流，每个流使用域ID标识自己。从服务器记录每个流的最后一个GTID，并跟踪其位置，实现从服务器多主，而主之间未互为复制时针对每个域的不同位置开始复制。
工作原理
-
master提交一个事务，产生GTID，同时记录到binlog中。
-
binlog传输到slave，并转存到relay-log，slave sql线程读取这个gtid并设置gtid_next变量，表示下一个要执行的gtid。
-
slave 读取到gtid首先对比slave的bin-log是否有该gtid，有表示执行过则忽略，无则判断其他session是否持有该gtid，有则避免重复执行，无则执行。
自动同步
- ABC三主机，A主BC从，当A主机宕机后，B主机升主，BC怎么确定bin-log文件和位置。当B升主，C连接到B，找到由A发来的最新gtid发送给B，B就从该gtid的下个gtid开始发送事务给C。
GTID使用
- 配置文件
主
server-id=n #server_id
log-bin='/path/filename' #bin-log日志
log_slave_updates=on #记录由replication机制sql线程读取，relay-log执行的sql语句记录到bin-log中
#由于binlog的产生会让从服务器复制数据，所以从服务器会多次复制一个事务。
从
server-id=n #server_id
relay-log='/path/filename' #relay-log日志
- 配置命令
CHANGE MASTER TO master_use_gtid = { slave_pos | current_pos | no }
slave_pos:服务器作为从服务器relay-log的的gtid
current_pos:服务器本地bin-log的gtid
no:不使用gtid，如果未显示关闭gtid，手动指定master_log_file和master_log_pos，依旧使用gtid
-
如果一个主服务器变为从服务器 master_use_gtid=current_pos；current_pos记录了服务器当前的最新状态，当他作为从服务器便以这个位置进行复制。
-
如果一个服务器作为从服务器 master_use_grid=slave_pos；因为当前服务器如果有DML、DDL语句时会改变current_pos，如果使用current_pos则会导致状态不一，应使用slave_pos。
M-S
- 添加配置
#mster_1
server-id=10
log-bin=/var/lib/mysql/master_1_bin
expire_logs_days=10
#slave_1
server-id=20
relay-log=/var/lib/mysql/slave_1_relay
- 授权账号
MariaDB [(none)]> grant replication slave, replication client on *.* to 'slave_1'@'10.10.10.%' identified by '123';
- 确定gtid
- 方式一：通过查看系统变量
MariaDB [(none)]> show master status;
+---------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------+----------+--------------+------------------+
| master_1_bin.000002 | 779 | | |
+---------------------+----------+--------------+------------------+
MariaDB [(none)]> select binlog_gtid_pos('master_1_bin.000002',779); #对应全局变量gtid_binlog_pos
+--------------------------------------------+
| binlog_gtid_pos('master_1_bin.000002',779) |
+--------------------------------------------+
| 0-10-46 |
+--------------------------------------------+
- 方式二：通过mysqldunmp
对主服务器已上线运行的可以采用该方法，通过备份恢复设定gtid，在恢复时应使用set sql_bin_log=0暂时关闭会话的二进制写入。
备份制定--master-data=1 --gtid
mysqldump --all-databases --single-transaction --master-data=1 --gtid -h'master1' -u'root' -p'123' > `date +%F`.sql
查看gtid
[root@slave1 ~]# egrep -i '(change master to master_use_gtid)|(set global gtid_slave_pos)' 2020-03-03.sql
CHANGE MASTER TO MASTER_USE_GTID=slave_pos;
SET GLOBAL gtid_slave_pos='0-10-46'
- slave配置
MariaDB [(none)]> set global gtid_slave_pos='0-10-46'
MariaDB [(none)]> change master to master_host='master_1', master_user='slave_1', master_password='123', master_use_gtid=slave_pos;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master_1
Master_User: slave_1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master_1_bin.000002 #bin-log文件
Read_Master_Log_Pos: 779 #bin-log位置
Relay_Log_File: slave_1_relay.000002 #relay-log文件
Relay_Log_Pos: 690 ##relay-log位置
Relay_Master_Log_File: master_1_bin.000002 #中继的日志文件
Slave_IO_Running: Yes #I/O线程
Slave_SQL_Running: Yes #SQL线程
Using_Gtid: Slave_Pos #使用的gtid
Gtid_IO_Pos: 0-10-46 #gtid值
...
M-M-S-S
- 10.10.10.10 master1
- 10.10.10.11 slave1
- 10.10.10.20 master2
- 10.10.10.21 slave2
实验中只对cr库进行复制
实验重点是在domain-id配置
M-M配置：
- 添加配置
#mater1的配置
server_id=10
gtid_domain_id=10
log-bin=master1_bin
expire_logs_days=10
binlog_do_db=cr
relay-log=master1_slave
#master2的配置
server_id=20
gtid_domain_id=20
log-bin=master2_bin
expire_logs_days=10
binlog_do_db=cr
relay-log=master2_slave
- 添加授权帐号
#master1 and master2
grant replication slave, replication client on *.* to 'slave'@'10.10.10.%' identified by '123';
- 确定gtid
master1设置gtid_slave_pos=20-20-1
master2设置gtid_slave_pos=10_10_1
#master1
set global gtid_slave_pos='20-20-1';
#master2
set global gtid_slave_pos='10-10-1';
- 互为slave配置
#master1
change master to master_host='master2', master_user='slave', master_password='123', master_use_gtid=slave_pos;
#master2
change master to master_host='master1', master_user='slave', master_password='123', master_use_gtid=slave_pos;
- 启动M-M
#master1 and master2
启动
start slave
查看
show slave status\G;
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
#master1
MariaDB [(none)]> show variables like '%gtid%';
+------------------------+-----------------+
| Variable_name | Value |
+------------------------+-----------------+
| gtid_binlog_pos | 10-10-1 |
| gtid_binlog_state | 10-10-1 |
| gtid_current_pos | 10-10-1,20-20-1 |
| gtid_domain_id | 10 |
| gtid_ignore_duplicates | OFF |
| gtid_pos_auto_engines | |
| gtid_seq_no | 0 |
| gtid_slave_pos | 20-20-1 |
| gtid_strict_mode | OFF |
| last_gtid | 10-10-1 |
| wsrep_gtid_domain_id | 0 |
| wsrep_gtid_mode | OFF |
+------------------------+-----------------+
#master2
MariaDB [(none)]> show variables like '%gtid%';
+------------------------+-----------------+
| Variable_name | Value |
+------------------------+-----------------+
| gtid_binlog_pos | 20-20-1 |
| gtid_binlog_state | 20-20-1 |
| gtid_current_pos | 10-10-1,20-20-1 |
| gtid_domain_id | 20 |
| gtid_ignore_duplicates | OFF |
| gtid_pos_auto_engines | |
| gtid_seq_no | 0 |
| gtid_slave_pos | 10-10-1 |
| gtid_strict_mode | OFF |
| last_gtid | 20-20-1 |
| wsrep_gtid_domain_id | 0 |
| wsrep_gtid_mode | OFF |
+------------------------+-----------------+
M-M-S-S
- 添加配置
#slave1
server_id=11
relay_log=slave1_relay
master-info-repository=table
relay-log-info-repository=table
#slave2
server_id=21
relay_log=slave1_relay
master-info-repository=table
relay-log-info-repository=table
- 确定gtid
#mster1
MariaDB [(none)]> show variables like '%gtid%';
+------------------------+-----------------+
| Variable_name | Value |
+------------------------+-----------------+
| gtid_binlog_pos | 10-10-2 |
| gtid_binlog_state | 10-10-2 |
| gtid_current_pos | 10-10-2,20-20-2 |
| gtid_domain_id | 10 |
| gtid_ignore_duplicates | OFF |
| gtid_pos_auto_engines | |
| gtid_seq_no | 0 |
| gtid_slave_pos | 20-20-2 |
| gtid_strict_mode | OFF |
| last_gtid | 10-10-2 |
| wsrep_gtid_domain_id | 0 |
| wsrep_gtid_mode | OFF |
+------------------------+-----------------+
#master2
MariaDB [(none)]> show variables like '%gtid%';
+------------------------+-----------------+
| Variable_name | Value |
+------------------------+-----------------+
| gtid_binlog_pos | 20-20-2 |
| gtid_binlog_state | 20-20-2 |
| gtid_current_pos | 10-10-2,20-20-2 |
| gtid_domain_id | 20 |
| gtid_ignore_duplicates | OFF |
| gtid_pos_auto_engines | |
| gtid_seq_no | 0 |
| gtid_slave_pos | 10-10-2 |
| gtid_strict_mode | OFF |
| last_gtid | 20-20-2 |
| wsrep_gtid_domain_id | 0 |
| wsrep_gtid_mode | OFF |
+------------------------+-----------------+
#slave1 and slave2
set global gtid_slave_pos='10-10-2,20-20-2';
- 两主两从配置
#master1 and master2
change master 'master1' to master_host='master1', master_user='slave', master_password='123', master_use_gtid=slave_pos;
change master 'master2' to master_host='master2', master_user='slave', master_password='123', master_use_gtid=slave_pos;
- 启动M-M-S-S
启动
start all slaves;
查看
show all slave status\G;
#show slave 'master1' status\G;
#show slave 'master2' status\G;
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
#slave1
MariaDB [(none)]> show variables like '%gtid%';
+------------------------+-----------------+
| Variable_name | Value |
+------------------------+-----------------+
| gtid_binlog_pos | |
| gtid_binlog_state | |
| gtid_current_pos | 10-10-2,20-20-2 |
| gtid_domain_id | 0 |
| gtid_ignore_duplicates | OFF |
| gtid_pos_auto_engines | |
| gtid_seq_no | 0 |
| gtid_slave_pos | 10-10-2,20-20-2 |
| gtid_strict_mode | OFF |
| last_gtid | |
| wsrep_gtid_domain_id | 0 |
| wsrep_gtid_mode | OFF |
+------------------------+-----------------+
#slave2
MariaDB [(none)]> show variables like '%gtid%';
+------------------------+-----------------+
| Variable_name | Value |
+------------------------+-----------------+
| gtid_binlog_pos | |
| gtid_binlog_state | |
| gtid_current_pos | 10-10-2,20-20-2 |
| gtid_domain_id | 0 |
| gtid_ignore_duplicates | OFF |
| gtid_pos_auto_engines | |
| gtid_seq_no | 0 |
| gtid_slave_pos | 10-10-2,20-20-2 |
| gtid_strict_mode | OFF |
| last_gtid | |
| wsrep_gtid_domain_id | 0 |
| wsrep_gtid_mode | OFF |
+------------------------+-----------------+
Galera
数据库管理系统（DBMS）：在单个节点上运行的数据库服务器。Galera群集可以使用MySQL、Mariadb或Percona xtradb。
wsrep api：Galera与数据库服务器的接口，为上层提供了丰富的状态信息和回调函数。wsrep api由wsrep hooks、dlopen函数两部分组成。wsrep hooks钩子程序用于与数据库服务器引擎集成。dlopen函数使Galera插件中的复制程序对wsrep hooks可用。
Galera复制插件：实现写集复制功能的核心模块。
组通信插件：Galera集群的组通信系统（Group Communication System，GCS），如GComm。
网络端口
标准MariaDB端口（默认：3306）-用于使用该方法的MySQL客户端连接和状态快照传输mysqldump。可以通过设置更改port。
Galera复制端口（默认：4567）-对于Galera群集复制通信，多播复制在此端口上同时使用UDP传输和TCP。可以通过设置进行更改wsrep_node_address。
IST端口（默认：4568）-用于增量状态传输。可以通过设置来改变ist.recv_addr在wsrep_provider_options。
SST端口（默认：4444）-适用于除以外的所有状态快照传输方法mysqldump。可以通过设置进行更改wsrep_sst_receive_address。
配置文件
[galera]
wsrep_on=ON #开启集群
wsrep_provider=/path/libgalera_smm.so #galera的模块
wsrep_cluster_address="gcomm://host1,..." #集群各节点主机
binlog_format=row #二进制日志格式
default_storage_engine=InnoDB #默认引擎
innodb_autoinc_lock_mode=2 #性能最好
bind-address=0.0.0.0 #galera服务监听地址
可选
wsrep_node_name=node1 #节点主机名
wsrep_node_address=10.10.10.21 #节点地址
wsrep_slave_threads=1 #并行复制线程数
innodb_flush_log_at_trx_commit=0 #0.log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行。该模式下在事务提交的时候，不会主动触发写入磁盘的操作。
#1：每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去，该模式为系统默认。
#2：每次事务提交时MySQL都会把log buffer的数据写入log file，但是flush(刷到磁盘)操作并不会同时进行。该模式下，MySQL会每秒执行一次 flush(刷到磁盘)操作
wsrep_sst_method=rsync #状态快照传输方法，mysqldump,mariabackup,rsync
实验环境
node1：10.10.10.21
node2：10.10.10.22
node3：10.10.10.23
M-M-M
- 安装软件包
我们在centos官方yum仓库安装，不使用mariadb的yum源。
如果使用mariadb的请看：官方安装说明
yum -y install mariadb-server-galera
#安装mariadb-server-galera
#会安装这些包组：mariadb mariadb-common mariadb-backup mariadb-server galera
- 初始化数据库
#node 1 and node2 and node3
rm -fr /var/lib/mysql/*
mysql_install_db --datadir=/var/lib/mysql/
chown mysql.mysql -R /var/lib/mysql/
- 配置hosts
10.10.10.21 node1
10.10.10.22 node2
10.10.10.23 node3
- 配置文件
#node1
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://node1,node2,node3"
wsrep_node_name=node1
...其他默认即可...
#node2
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://node1,node2,node3"
wsrep_node_name=node2
...其他默认即可...
#node3
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://node1,node2,node3"
wsrep_node_name=node3
...其他默认即可...
- 启动集群
- 集群中任一节点首先启动初始化集群
#node
/usr/libexec/mysqld --user=mysql --wsrep-new-cluster > mysql.log 2>&1
- 其他节点正常启动即可
#node2 and node3
systemctl start mariadb
- 查看状态
#wsrep_cluster_size 状态变量和配置的节点数一致说明节点以全部加入集群
show status like "%wsrep%";
+-------------------------------+----------------------------------------------------+
| Variable_name | Value |
+-------------------------------+----------------------------------------------------+
| wsrep_applier_thread_count | 1 |
| wsrep_apply_oooe | 0.000000 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.000000 |
| wsrep_causal_reads | 0 |
| wsrep_cert_deps_distance | 1.000000 |
| wsrep_cert_index_size | 1 |
| wsrep_cert_interval | 0.000000 |
| wsrep_cluster_conf_id | 5 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | 2d5fc536-5e1f-11ea-ac92-ca943ada5292 |
| wsrep_cluster_status | Primary |
| wsrep_cluster_weight | 3 |
| 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 | 6ae9416a-5e1f-11ea-9663-e355d2a2849c |
| wsrep_incoming_addresses | 10.10.10.21:3306,10.10.10.22:3306,10.10.10.23:3306 |
| wsrep_last_committed | 1 |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_cached_downto | 1 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_commits | 0 |
| wsrep_local_index | 1 |
| 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 | 2d5fc536-5e1f-11ea-ac92-ca943ada5292 |
| wsrep_open_connections | 0 |
| wsrep_open_transactions | 0 |
| wsrep_protocol_version | 9 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 3.26(rXXXX) |
| wsrep_ready | ON |
| wsrep_received | 5 |
| wsrep_received_bytes | 940 |
| 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_rollbacker_thread_count | 1 |
| wsrep_thread_count | 2 |
+-------------------------------+----------------------------------------------------+
- 测试
#在node1创建数据库d1
create database d1;
#node2 and node3
show databases;
254
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
