MySQL 8.0.32 MGR常见操作及添加新节点

IT_木头人

已于 2023-06-02 17:48:58 修改

阅读量915

点赞数

分类专栏： MySQL 文章标签： mysql 数据库

于 2023-06-02 17:31:39 首次发布

本文链接：https://blog.csdn.net/qq_15638331/article/details/131011235

版权

MySQL 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

MySQL 8.0.32 MGR常见操作及添加新节点

启动MGR

单主模式启动

第一个节点（引导）：

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

其他节点：

START GROUP_REPLICATION;

多主模式启动

所有节点设置多主模式

  set global group_replication_single_primary_mode=OFF;
  set global group_replication_enforce_update_everywhere_checks=ON;

第一个节点（引导）：

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

其他节点：

  START GROUP_REPLICATION;

MGR单主多主模式切换

多主切换为单主

在任一节点上执行：
```
select group_replication_switch_to_single_primary_mode('39e6b044-cc8c-11ed-ba9f-000c2930b9bc');
```
说明：39e6b044-cc8c-11ed-ba9f-000c2930b9bc为需要指定为主节点的MEMBER_ID

单主切换为单主

在任一节点上执行：

SELECT group_replication_switch_to_multi_primary_mode();

单主模式下切换主节点
```
SELECT group_replication_set_as_primary('39e6b044-cc8c-11ed-ba9f-000c2930b9bc',300);
```
说明：39e6b044-cc8c-11ed-ba9f-000c2930b9bc为要主节点的member_id；300为超时时间，单位为秒，8.0.29后开始有此参数，设置了超时时间，那么会阻止主服务上启动新事务，当到达超时时间后，未提交的事务客户端会断开连接，事务不会继续。

组的写入并发性

检查组的写入并发性

SELECT group_replication_get_write_concurrency();

设置组的写入并发性

SELECT group_replication_set_write_concurrency(instances);

添加新节点

因为MGR的同步是基于binlog和GTID实现的，所以添加新节点时所要解决的核心问题就是原有数据同步以及新节点GTID设置。在添加新节点前，需要评估一下当前MGR的情况，以便于确定最优的添加方案，主要需要考虑以下几点：

1、原有数据如何同步到新节点？

2、原MGR节点中的binlog日志保留了多久？是否完整？

3、新节点的GTID如何设置？

4、原MGR各节点的MySQL版本是多少？以及系统环境是否一样？

根据评估情况，基本上可以确定最优的添加方案，不过不管是哪种方案，大体步骤都差不多，主要的区别在于原有数据同步恢复方式。大体步骤如下：

配置新节点

server_id=1  #与原MGR各节点server_id需要不一样
gtid_mode=ON
enforce_gtid_consistency=ON
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" #与原MGR保持一致
group_replication_start_on_boot=off
group_replication_local_address= "192.168.109.144:33061" #修改为新节点ip
group_replication_group_seeds= "192.168.109.144:33061,192.168.109.145:33061,192.168.109.146:33061"
group_replication_bootstrap_group=off
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
report_host=192.168.109.144  #对应节点ip，默认使用主机名连接各节点，故要配置通过ip
report_port=3306

修改原mgr各节点配置

mysql>set global group_replication_group_seeds= "192.168.109.144:33061,192.168.109.145:33061,192.168.109.146:33061";

注意同时修改/etc/my.cnf中group_replication_group_seeds的值与上面一致。

同步恢复数据

这一步也是整个添加方案中，变化最大的一步，不同的情况我们可以采用不同的数据同步恢复方案，这里介绍一下常用的三种数据同步恢复方案。
- mysqldump备份恢复数据
在MGR任一节点（最好是secondary节点）执行数据备份命令：
```
mysqldump -uroot -p --single-transaction  --source-data=2 -R -E --all-databases >mgr.sql
```
这里备份的是所有库，也可只备份业务库，但若只备份业务库需要自行创建同步等相关账号，建议备份所有库。

查看备份的GTID：

在新节点导入数据并检查GTID设置：
```
mysql -uroot -p < mgr.sql
```
若MySQL为5.7，导入时会报错ERROR 1030(HYO00)at line 76: Got error 168 from storage engine，这是因为MySQL 5.7系统表使用的是MyISAM存储引擎，而/etc/my.cnf中有一项disabled_storage_engines=“MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY”

故而无法创建MyISAM表，由于此参数是read-only的参数，在/etc/my.cnf中注释掉，重启mysqld，导入成功；然后去掉注释，重启mysqld，重新启用disabled_storage_engines=“MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY”。MySQL 8.0中不存在这个问题，因为8.0的系统表都是使用的innodb存储引擎。

查看GTID：
- 使用xtrabackup备份恢复数据
在MGR一节点（最好是secondary节点）和新节点上安装xtrabackup工具：
```
yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
percona-release enable-only tools release
yum install percona-xtrabackup-80
```
在MGR Primary节点上对备份账号授权，这里我们使用root账号
```
mysql> grant backup_admin  on *.* to root@'%';
Query OK, 0 rows affected (0.01 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
```
备份数据
```
xtrabackup --user=root --password='Zkk@123456' --backup --target-dir=/data/backups/
```
将备份数据拷贝到新节点执行恢复
```
xtrabackup --prepare --target-dir=/root/backups/
xtrabackup --copy-back --target-dir=/root/backups/  
chown -R mysql.mysql /var/lib/mysql   #注意datadir路径及目录权限，且要为空目录
systemctl start mysqld.service   #启动MySQL
```
查看备份文件xtrabackup_binlog_info中的GTID值

检查新节点GTID值

如果新节点的GTID与xtrabackup_binlog_info中GTID不一致，需要重新设置新节点的GTID：
```
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL gtid_purged='<gtid_string_found_in_xtrabackup_binlog_info>';
```
- 使用mysql_clone插件同步恢复数据
在MGR primary节点上给clone账号授权
```
mysql> GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
mysql> grant CLONE_ADMIN on *.* to 'root'@'%'; #新节点执行clone的账号要有clone权限
mysql> flush privileges;
```
在MGR secondary节点及新节点上安装mysql_clone插件
```
plugin_load_add='mysql_clone.so'  #添加到/etc/my.cnf文件[mysqld]下

systemctl restart mysqld.service  #重启mysql
```
这里也可以直接在mysql中执行INSTALL PLUGIN clone SONAME ‘mysql_clone.so’;在线安装，但是因为secondary节点是–super-read-only，所以在secondary状态下无法直接在线安装。

查看安装的插件
```
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';
```
设置从MGR集群的secondary节点克隆
```
SET GLOBAL clone_valid_donor_list = '192.168.109.145:3306';
```
开始克隆且克隆后此实例会自动重启mysqld
```
CLONE INSTANCE FROM 'rpl_user'@'192.168.109.145':3306 IDENTIFIED BY 'Zkk@123456';
```
说明：如果MGR集群是全新部署的且binlog完整，那么可以跳过复制数据，让MGR自行追平数据。
新节点加入MGR，并检查状态

配置同步账号：
```
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='Zkk@123456' FOR CHANNEL 'group_replication_recovery';
```
实际上，如果是全库备份恢复的，这里可以不在配置同步账号，因为账号已经保存在performance_schema.replication_connection_configuration表了，可以查看确认一下：

新节点上启动GROUP_REPLICATION：
```
START GROUP_REPLICATION;
```
查看MGR状态：