8.Mysql之MGR环境搭建

1.前言

  之前主要讲解了关于MGR的一些工作原理以及限制,那么今天这里主要操作MGR,

2.环境准备

  Mysql版本:mysql8.0.25

  10.211.55.230:3306

  10.211.55.220:3306

  10.211.55.210:3306

  说明:这里主要搭建的是单机多实例单主模式的MGR环境

3.配置文件参数(必须要有的) 

复制代码
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE
transaction_write_set_extraction=XXHASH64
loose-plugin_load_add='group_replication.so'
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"   # 这里的所有节点都要配置相同
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "s1:33061"
loose-group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
loose-group_replication_bootstrap_group=off
default_authentication_plugin = mysql_native_password # 这里注意需要这个密码插件,不然会默认caching_sha2_password
复制代码

里面的参数值要根据实际的来配置:https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-instances.html

说明

想要使用组复制,要求还是挺多的。分析一下上面的配置选项:

  • (1).因为组复制基于GTID,所以必须开启gtid_mode和enforce_gtid_consistency。
  • (2).组复制必须开启二进制日志,且必须设置为行格式的二进制日志,这样才能从日志记录中收集信息且保证数据一致性。所以设置log_bin和binlog_format。
  • (3).由于MySQL对复制事件校验的设计缺陷,组复制不能对他们校验,所以设置binlog_checksum=none,该参数在8.0.21版本后就不需要设置了。
  • (4).组复制要将master和relay log的元数据写入到mysql.slave_master_info和mysql.slave_relay_log_info中。
  • (5).组中的每个节点都保留了完整的数据副本,它是share-nothing的模式。所以所有节点上都必须开启log_slave_updates,这样新节点随便选哪个作为donor都可以进行异步复制。
  • (6).sync_binlog是为了保证每次事务提交都立刻将binlog刷盘,保证出现故障也不丢失日志。
  • (7).最后的6行是组复制插件的配置。以loose-开头表示即使启动组复制插件,MySQL也继续正常允许下去。这个前缀是可选的。
  • (8).倒数第6行表示写集合以XXHASH64的算法进行hash。所谓写集,是对事务中所修改的行进行的唯一标识,在后续检测并发事务之间是否修改同一行冲突时使用。它基于主键生成,所以使用组复制,表中必须要有主键。
  • (9).倒数第5行表示这个复制组的名称。它必须是一个有效的UUID值。嫌可以直接和上面一样全写字母a。在Linux下,可以使用uuidgen工具来生成UUID值。
[root@xuexi ~]# uuidgen
09c38ef2-7d81-463e-bdb4-9459b2c0e49b
  • (10).倒数第4行表示组复制功能不随MySQL实例启动而启动。虽然,可以将组复制插件和启动组复制功能的选项写在配置文件里,但强烈建议不要如此,而是每次手动去配置。
  • (11).倒数第3行表示该节点在组中的权重为40。权重越高,自动选举为primary节点的优先级就越高。
  • (12).倒数第2行表示本机上用于组内各节点之间通信的地址和端口
  • (13).最后一行,设置本组的种子节点。种子节点的意义在前文已经解释过了。

4.部署

 Master上操作:

复制代码
1.首先创建复制用户,并授予replication slave权限
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' identified by 'rpl_pass';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

2.创建一个复制通道channel
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass'
        FOR CHANNEL 'group_replication_recovery';

3.安装group_replication的插件plugin
INSTALL PLUGIN group_replication SONAME 'group_replication.so';

4.设置group_replication_bootstrap_group为ON是为了标示以后加入集群的服务器以这台服务器为基准,以后加入的就不需要设置
SET GLOBAL group_replication_bootstrap_group=ON;
# 5.开启group_replication
# set global slave_preserve_commit_order=1; ##这里需要注意,如果当开启组复制的时候报错(因为这里开了并行复制),那么需要在开启之前执行该行命令,
start group_replication;
SET GLOBAL group_replication_bootstrap_group=OFF;
#查看MGR的状态 select *from performance_schema.replication_group_members;
复制代码

 Slave上操作

复制代码
1.首先创建复制用户,并授予replication slave权限
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' identified by 'rpl_pass';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

2.创建一个复制通道channel
CHANGE MASTER TO MASTER_USER='rpl_user',MASTER_PASSWORD='rpl_pass'
        FOR CHANNEL 'group_replication_recovery';

3.安装group_replication的插件plugin
INSTALL PLUGIN group_replication SONAME 'group_replication.so';

4.开启group_replication
#set global slave_perserve_commit_order=1; 如果开了并行复制,在开启组复制之前先要执行这条命令 start group_replication;
#查看MGR的状态 select *from performance_schema.replication_group_members;
复制代码

  特别需要注意的是,Master配置中,需要将参数group_replication_bootstrap_group设置为on,设置group_replication_bootstrap_group为ON是为了标示以后加入集群的服务器以这台服务器为基准,以后加入的就不需要设置,(而Slave中需要将group_replication_allow_local_disjoint_gtids_join设置为on,允许当前服务器加入该组,即使该组中没有事务。如果不添加这个参数,日志中将会给出下面的提示:Plugin group_replication reported: 'To force this member into the group you can use the group_replication_allow_local_disjoint_gtids_join option',这一点是Master和Slave搭建时候的重要区别) -----> 该参数在mysql8.0.4版本中移除了。

5.主备切换(自动切换or手工切换)

 5.1查看状态 

复制代码
root@mysqldb 21:52:  [(none)]> select *from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 34333d7b-c7fe-11ed-a919-001c42402fec | mysql03     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | df99817c-c7f3-11ed-819f-001c424f0ae4 | mysql02     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | e2a24691-c7f1-11ed-9597-001c4294d606 | mysql01     |        3306 | ONLINE       | PRIMARY     | 8.0.25         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
复制代码

 5.2 切换测试(自动切换)

  查看切换之前的主节点

root@mysqldb 09:37:  [(none)]> 

+----------------------------------+--------------------------------------+-------------+-------------+
| variable_name                    | member_id                            | member_host | member_port |
+----------------------------------+--------------------------------------+-------------+-------------+
| group_replication_primary_member | e2a24691-c7f1-11ed-9597-001c4294d606 | mysql01     |        3306 |
+----------------------------------+--------------------------------------+-------------+-------------+

  停止主节点mysql01,可以看到其状态是offline  

root@mysqldb 09:37:  [(none)]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 34333d7b-c7fe-11ed-a919-001c42402fec | mysql03     |        3306 | ONLINE       | PRIMARY     | 8.0.25         |
| group_replication_applier | df99817c-c7f3-11ed-819f-001c424f0ae4 | mysql02     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)

  发现主节点变成了mysql03了。

  上面是MGR的自动切换,当主库宕机了,mgr会根据内部规则怎样将其中一个备库提升为主库

5.3 切换测试(手工切换)

SELECT group_replication_set_as_primary(member_uuid);  # version :8.0.29 before
SELECT group_replication_set_as_primary(‘00371d66-3c45-11ea-804b-080027337932’, 300)   # version: 8.0.29 or later

6.节点选举的问题

参数:global group_replication_member_weight=xxx 

root@mysqldb 22:00:  [(none)]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 34333d7b-c7fe-11ed-a919-001c42402fec | mysql03     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | df99817c-c7f3-11ed-819f-001c424f0ae4 | mysql02     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | e2a24691-c7f1-11ed-9597-001c4294d606 | mysql01     |        3306 | ONLINE       | PRIMARY     | 8.0.25         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

  下面的切换测试中,我的主节点是mysql01,按照下面的权重值进行设置,当停掉mysql01的时候,系统会选举mysql03来作为新的master,因为它的权重值比mysql02要重,所以我们可以通过设置某个节点的权重来指定我们想要选举的新master,如下: 

mysql02
mysql--root@localhost:(none) 18:47:24>>set global group_replication_member_weight=45;
Query OK, 0 rows affected (0.00 sec)
mysql03
mysql--root@localhost:(none) 18:35:18>>set global group_replication_member_weight=50;
Query OK, 0 rows affected (0.00 sec)

注意:这里的3307是我们第一次搭建时的基准节点,因此当搭建完MGR后,它一般就是我们的主节点,而当主节点宕机后,系统会根据3308和3309的权重来进行选举新的主节点,那个权重值大就会选举那个节点作为主节点

复制代码
root@mysqldb 22:06:  [(none)]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 34333d7b-c7fe-11ed-a919-001c42402fec | mysql03     |        3306 | ONLINE       | PRIMARY     | 8.0.25         |
| group_replication_applier | df99817c-c7f3-11ed-819f-001c424f0ae4 | mysql02     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.03 sec)

root@mysqldb 22:07:  [(none)]> select variable_name,member_id,member_host,member_port from performance_schema.global_status a,performance_schema.replication_group_members b where a.variable_value=b.member_id;
+----------------------------------+--------------------------------------+-------------+-------------+
| variable_name                    | member_id                            | member_host | member_port |
+----------------------------------+--------------------------------------+-------------+-------------+
| group_replication_primary_member | 34333d7b-c7fe-11ed-a919-001c42402fec | mysql03     |        3306 |
+----------------------------------+--------------------------------------+-------------+-------------+
1 row in set (0.02 sec)
复制代码

 7.自增列测试

root@localhost 23:14:  [liulin]> show variables like '%auto_incr%';
+--------------------------------------------+-------+
| Variable_name                              | Value |
+--------------------------------------------+-------+
| auto_increment_increment                   | 1     |
| auto_increment_offset                      | 1     |
| group_replication_auto_increment_increment | 7     |
+--------------------------------------------+-------+

  经过我的测试,这里应该主要看的是参数:auto_increment_increment 表示的是自增步长的配置信息,auto_increment_increment,在GROUP中范围在1-9(因为一个GROUP最多只能有9个组成员),GROUP中安装的时候,默认为7;

  如果我们想要修改该自增步长时,需要我们先把复制给停掉,然后才能修改参数

8.节点的接入

  这里的节点接入采用克隆插件的方式进行数据的克隆然后接入到MGR中,假如当前的MGR的组成员如下:一主一从格式: 

root@mysqldb 22:06:  [(none)]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 34333d7b-c7fe-11ed-a919-001c42402fec | mysql03     |        3306 | ONLINE       | PRIMARY     | 8.0.25         |
| group_replication_applier | df99817c-c7f3-11ed-819f-001c424f0ae4 | mysql02     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.03 sec)

  这里选择主节点(mysql01)进行数据克隆(主要使用的远程克隆方法)

  1.在mysql01上面配置好参数文件,然后再初始化数据库

  2.主节点和要添加的新节点都要安装一下克隆插件

  3.在主节点和从节点创建用户

  4.在新节点上执行克隆命令,将数据库拉取过来

  5.将新节点加入到MGR中

复制代码
root@mysqldb 22:53:  [test]> start group_replication;
Query OK, 0 rows affected (4.51 sec)

root@mysqldb 22:53:  [test]> 
root@mysqldb 22:53:  [test]> 
root@mysqldb 22:53:  [test]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 14fcd5e8-ce3d-11ed-b8ed-001c4294d606 | mysql01     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | 34333d7b-c7fe-11ed-a919-001c42402fec | mysql03     |        3306 | ONLINE       | PRIMARY     | 8.0.25         |
| group_replication_applier | df99817c-c7f3-11ed-819f-001c424f0ae4 | mysql02     |        3306 | ONLINE       | SECONDARY   | 8.0.25         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
复制代码

 

posted on   太白金星有点烦  阅读(369)  评论(0编辑  收藏  举报

编辑推荐:
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
阅读排行:
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· Manus爆火,是硬核还是营销?
· 一文读懂知识蒸馏
· 终于写完轮子一部分:tcp代理 了,记录一下

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
点击右上角即可分享
微信分享提示