2.1.4、MySQL Group复制（宝塔）

本文章介绍下MySQL基于Group复制的主从搭建（当MySQL5.7的版本安装好后，在数据目录下有一个auto.cnf的文件，就是存放着server-uuid）：

查看 GTID 的相关的一些变量：

mysql> show variables like '%gtid%';
+----------------------------------+-----------+
| Variable_name                    | Value     |
+----------------------------------+-----------+
| binlog_gtid_simple_recovery      | ON        |
| enforce_gtid_consistency         | OFF       |
| gtid_executed_compression_period | 1000      |
| gtid_mode                        | OFF       |
| gtid_next                        | AUTOMATIC |
| gtid_owned                       |           |
| gtid_purged                      |           |
| session_track_gtids              | OFF       |
+----------------------------------+-----------+
8 rows in set (0.00 sec)

可以看到，官方的MySQL5.7 默认是没开启GTID的。

一、主库配置

点击首页上的 MySQL 服务图标，进入配置界面：

选择配置修改，可见 MySQL 服务当前的配置内内容：

配置 my.cnf

[mysqld]
#gtid 参数
gtid_mode=ON
enforce-gtid-consistency=ON
#开启log-bin二进制日志
log-bin=mysql-bin
#允许从服务器更新二进制日志
log-slave-updates=1

#配置唯一的服务器ID，一般使用IP最后一位
server-id=81

#GTID 复制时，binlog 使用 ROW 模式
binlog_format=row
#不需要同步的数据库，如果有多个，复制多份指定数据库名即可
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
binlog-ignore-db=performance_schema
binlog-ignore-db=sys

#下面不是必须配置
#使用带事务的InnoDB进行复制设置时尽可能提高持久性和一致性
innodb_flush_log_at_trx_commit=1
#使binlog在每1次binlog写入后与硬盘同步
sync_binlog=1
#只保留10天的二进制日志，以防磁盘被日志占满
expire-logs-days=10

上述参数中，比较重要的参数介绍：

(1)、server-id：主从复制中必须的参数，且一个主从复制集群中是必须唯一的。
(2)、binlog_format=row ：二进制日志的存储模式，GTID 复制时，使用 ROW 行模式。
(3)、 gtid_mode=ON：表示开启 GTID 模式的主从复制。如果为 OFF ，则不启用 GTID 复制模式，而是普通的异步复制模式。
(4)、enforce-gtid-consistency=ON ：表示开启强一致性，必须设置为 ON。

检验设置是否成功

先使用下面命令登录数据库：

mysql -uroot -p9e1293cf0855f12e

登录成功后输入下面命令检查：

show variables like 'server_id';

再输入命令：

show variables like 'log_bin';

再输入命令：

#skip_networking默认是OFF关闭状态，启用后，主从服务器将无法相互通信，所以这里必须是 OFF
show variables like '%skip_networking%';

全部检查完毕，主节点设置完成!

二、MySQL主数据库，建立主从复制的账号

执行下面命令：

GRANT REPLICATION SLAVE ON *.* to 'duplicator'@'%' identified by 'Ds472HFfiTTckXNB';
GRANT SUPER ON *.* to 'duplicator'@'%' identified by 'Ds472HFfiTTckXNB';
GRANT RELOAD ON *.* to 'duplicator'@'%' identified by 'Ds472HFfiTTckXNB';

一定要记得授权，不然会报下面的错误：

注意：
上面SQL的作用是创建一个用户【duplicator】密码为【Ds472HFfiTTckXNB】并且给【duplicator】用户授予REPLICATION SLAVE 权限，常用于建立复制时所需要用到的用户权限，也就是slave必须被master授权具有该权限的用户，才能通过该用户复制，如下：

然后执行下面命令：

#查看master的状态
show master status\G

主库已经配置好了，下面我们开始配置从库

三、从库配置

先在从库上执行下面语句检查下刚刚建立的账号是否可以连接

#IP是主库IP
mysql -uduplicator -p'Ds472HFfiTTckXNB' -h192.168.3.81

如果连接失败，说明使用的主库账号的远程访问权限没开启（需要开启远程访问权限），参考《MySQL 远程访问权限》的文章中说明开启主节点的root账号的远程访问，开启后再次重试如下：

配置 my.cnf

然后在【mysqld】节点下面新增下面内容：

[mysqld]
#gtid 参数
gtid_mode=ON
enforce-gtid-consistency=ON

#开启log-bin二进制日志
log-bin=mysql-bin
#使得更新的数据写进二进制日志中
log-slave-updates=1

#配置唯一的服务器ID，一般使用IP最后一位
server-id=82

#GTID 复制时，binlog 使用 ROW 模式
binlog_format=row
#需要同步的数据库，如果有多个，复制多份指定数据库名即可
#此处表示同步testdb
binlog_do_db=testdb

#relay-log-info-repository=TABLE
#relay-log-recovery
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin

如下：

然后重启数据库，并查看刚配置的是否生效：

使用从数据库账号登录：

mysql -uroot -p42d464110d0c139f;
show variables like 'server_id';
show variables like 'log_bin';

如果报错：

那就执行：

ALTER USER USER() IDENTIFIED BY '42d464110d0c139f!';

就可以了执行了：

配置复制参数

执行下面命令（从数据库账号登录后操作）：

CHANGE MASTER TO MASTER_HOST='192.168.3.81',MASTER_PORT=13306,MASTER_USER='duplicator',MASTER_PASSWORD='Ds472HFfiTTckXNB',MASTER_AUTO_POSITION=1;

下面是主库的参数：

如果执行提示下面失败，表示权限不足：

授权后再执行前面的SQL, 如果执行失败，就执行：reset slave;

我这里执行成功了，就可以执行下面SQL语句启动主从了：

start slave;

查看主库状态

执行下面命令查看从库状态：

show master status\G

查看从库状态

执行下面命令查看从库状态：

show slave status\G

参数介绍：

# 负责与主机的io通信
Slave_IO_Running: Yes

# 负责自己的slave mysql进程
Slave_SQL_Running: Yes

若出错，则清理掉之前的配置，执行以下命令：

mysql> stop slave;
mysql> reset slave all;

注：Slave_IO_Running：写入状态。Slave_SQL_Running：本地数据库运行状态。当2个状态均为yes时，证明数据库主从状态设置成功。

show variables like 'datadir';
select uuid();

如果`Slave_IO_Running`状态为no的时候，可能是server uuid的值就和主服务器是一样的。因为是复制来的，可能一样。这个时候，可以将从服务器里面的 auto.cnf 文件删除。重启服务就会生成一个新的。

如果`Slave_SQL_Running`状态为No时，一般是主从数据库的初始数据不一致导致的。

解决上面问题之后。再次执行配置从服务器Slave，当2个都为yes的时候，主从服务器配置完成。可以在主库新建一个数据库。从库就会自动创建。这时候不要去操作从库，因为修改会导致主从失败。

测试

在我本地用Navicat工具连接主库和从库：

当前两个库都是一样的库，现在在主库上面新建一个【testdb】数据库，然后从库直接刷新，就可以看到这个数据库了，同样的，你在主库上新建什么表，添加什么数据，刷新从库后，会发现，数据都在了，说明测试成功了，现在主从复制功能就实现了：

4，开启Group Replication

有了gtid之后，开启group replication就方便多了。首先需要安装group replication插件

mysql> INSTALL PLUGIN group_replication SONAME ‘group_replication.so’;

Query OK, 0 rows affected (0.03 sec)

mysql> show plugins;

+—————————-+———-+——————–+———————-+———+

+—————————-+———-+——————–+———————-+———+

…………

+—————————-+———-+——————–+———————-+———+

45 rows in set (0.00 sec)

配置参数，db1（master）上：

mysql> set @@global.transaction_write_set_extraction = XXHASH64

mysql> set @@global.group_replication_start_on_boot = OFF

mysql> set @@global.group_replication_bootstrap_group = OFF

mysql> set @@global.group_replication_group_name = 0c6d3e5f-90e2-11e6-802e-842b2b5909d6

mysql> set @@global.group_replication_local_address = ‘db1:6606’

mysql> set @@global.group_replication_group_seeds = ‘db2:6607,db3:6608’

配置参数，db2（slave1）上：

mysql> set @@global.transaction_write_set_extraction = XXHASH64

mysql> set @@global.group_replication_start_on_boot = OFF

mysql> set @@global.group_replication_bootstrap_group = OFF

mysql> set @@global.group_replication_group_name = 0c6d3e5f-90e2-11e6-802e-842b2b5909d6

mysql> set @@global.group_replication_local_address = ‘db2:6607’

mysql> set @@global.group_replication_group_seeds = ‘db111:6606,127.0.0.1:db3’

配置参数，db3（slave2）上：

mysql> set @@global.transaction_write_set_extraction = XXHASH64

mysql> set @@global.group_replication_start_on_boot = OFF

mysql> set @@global.group_replication_bootstrap_group = OFF

mysql> set @@global.group_replication_group_name = 0c6d3e5f-90e2-11e6-802e-842b2b5909d6

mysql> set @@global.group_replication_local_address = ‘db3:6608’

mysql> set @@global.group_replication_group_seeds = ‘db1:6607,db2:6606’

BTY：如果之前没有配置transaction_write_set_extraction=XXHASH64，这里修改之后之前创建的数据库是没有办法执行插入操作的。所有如果想在线完成Group Replication的改造需要保证之前已经设置了transaction_write_set_extraction=XXHASH64。

开始构建集群，在db1（master）上执行：

#
构建集群

CHANGE MASTER
TO
MASTER_USER=
‘repl’
, MASTER_PASSWORD=
‘rlpbright1927@ys’FORCHANNEL’groupreplication_recovery’
;

#
开启
group_replication

SETGLOBAL group_replication_bootstrap_group=ON;

START GROUP_REPLICATION;

SETGLOBAL group_replication_bootstrap_group=OFF;

db2、db3上加入

stop slave;

START GROUP_REPLICATION;

在db1上查看集群信息：

mysql> SELECT * FROM performance_schema.replication_group_members;
————————————————
版权声明：本文为CSDN博主「林震南」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/csdnhsh/article/details/95767467

作者：Jeebiz 创建时间：2023-01-16 21:41
最后编辑：Jeebiz 更新时间：2024-08-22 10:22

2.1.4、MySQL Group复制（宝塔）

一、主库配置

配置 my.cnf

检验设置是否成功

二、MySQL主数据库，建立主从复制的账号

三、从库配置

配置 my.cnf

配置复制参数

查看主库状态

查看从库状态

如果Slave_IO_Running状态为no的时候，可能是server uuid的值就和主服务器是一样的。因为是复制来的，可能一样。这个时候，可以将从服务器里面的 auto.cnf 文件删除。重启服务就会生成一个新的。

如果Slave_SQL_Running状态为No时，一般是主从数据库的初始数据不一致导致的。

测试

如果`Slave_IO_Running`状态为no的时候，可能是server uuid的值就和主服务器是一样的。因为是复制来的，可能一样。这个时候，可以将从服务器里面的 auto.cnf 文件删除。重启服务就会生成一个新的。

如果`Slave_SQL_Running`状态为No时，一般是主从数据库的初始数据不一致导致的。