关注我「程序猿集锦」,获取更多分享。
- 前言
- MGR的介绍
- MGR的演变过程
- 什么是MGR
- MGR的工作模式
- MGR集群的限制
- 环境准备
- Docker网段的准备
- MySQL容器的启动
- MGR插件的安装
- MGR安装方式一
- MGR安装方式二
- MGR集群的配置
- 修改主机hosts文件
- 修改my.cnf配置文件
- MGR集群的启动
- master1节点的初始化
- master2节点加入MGR集群
- master3节点加入MGR集群
前言
前面我们分别介绍了MySQL高可用集群MMM架构、MHA架构,今天我们来看下另外一中高可用的MySQL集群架构-MGR(MySQL Group Replication)。
MGR的介绍
MGR的演变过程
说道MGR,就不得不提一下MySQL主从复制的模式:异步复制、半同步复制、同步复制。这个顺序也是这三种复制模式出现的先后顺序。
在早些时候,MySQL的主从复制是异步进行的,master主上面的数据写完之后就返回给客户端了,不会在乎这个操作是否已经被同步到了slave从节点。这也就是异步复制的概念。其过程可以参考下图:
基于异步复制的主从架构有一个比较严重的问题:主从延迟。当在主上执行了一个写入的操作后,这个操作要等待一定的时间才可以同步到从上,即便这个时间比较短,但是对于一些时效性要求比较高的应用来说也是不能接受的。特别是大事务的操作时候,这种现象尤其的明显。
除了主从延迟之外,还有另外一个问题就是有可能主从数据不一致,数据丢失的情况。如果在master上记录了binlog,并提交了事务,但是这个binlog因为网络问题、或延迟的问题并没有传送到slave节点,而这个时候,master宕机了,服务切换到slave上,就导致了刚才在master上提交的事务在salve上丢失了。
为了解决这些问题,MySQL在5.7版本中提出了半同步复制的概念。在半同步复制中,当写的操作在主上执行并记录binlog之后,此时并不会马上提交事务并返回给客户端,而是等待从节点同步了此次操作并给主节点反馈一个同步到此次操作的binlog消息,在主收到此消息之后才会将事务提交并反馈给客户单执行结果。半同步复制的流程,如下所示:
半同步复制基本能够保证数据的一致性,但在对事务一致性要求很高的系统中,还是存在一些不足,主要的不足就是主从之间的事务不能保证时刻同步并完全一致。基于半同步复制的高可用方案也存在主备不一致的风险,原因在于当master将事务写入binlog,尚未传送给slave时master故障,此时应用切换到slave,虽然此时slave的事务与master故障前是一致的,但当主机恢复后,因最后的事务已经写入到binlog,所以在master上会恢复成已提交状态,从而导致主从之间的事务不一致。
所以在半同步复制的基础上,就是全同步复制的实现,也就是今天我们要说的基于组的主从复制架构MGR,其过程如下所示:
什么是MGR
MGR(MySQL Group Replication)是 MySQL 自带的一个插件,可以灵活部署。MySQL MGR 集群是多个 MySQL Server 节点共同组成的分布式集群,每个 Server 都有完整的副本,它是基于 ROW 格式的二进制日志文件和 GTID 特性。是MySQL5.7版本出现的新特性,提供高可用、高扩展、高可靠(强一致性)的MySQL集群服务。 MGR由多个实例节点共同组成一个数据库集群,系统提交事务必须经过半数以上节点同意方可提交,在集群中每个节点上都维护一个数据库状态机,保证节点间事务的一致性。
Group Replication由至少3个或更多个节点共同组成一个数据库集群,事务的提交必须经过半数以上节点同意方可提交,在集群中每个节点上都维护一个数据库状态机,保证节点间事务的一致性。Group Replication基于分布式一致性算法Paxos实现,允许部分节点故障,只要保证半数以上节点存活,就不影响对外提供数据库服务,是一个真正可用的高可用数据库集群技术。Group Replication支持两种模式,单主模式和多主模式。在同一个group内,不允许两种模式同时存在,并且若要切换到不同模式,必须修改配置后重新启动集群。在单主模式下,只有一个节点可以对外提供读写事务的服务,而其它所有节点只能提供只读事务的服务,这也是官方推荐的Group Replication复制模式。
MGR的工作模式
MGR工作模式
- 单主模式:只要一个master节点可以提供写的服务,其他slave从节点只能提供读的服务,并且这些从节点的read_only的属性值为on。这也是MGR默认的工作模式。如果master宕机之后,会从slave中选举一个新的slave作为主节点,并将这个新的主节点设置为可读,其他节点指向这个新的master节点。
- 多主模式:所有的节点都可以提供读写的服务,此时的MGR集群中没有master和slave的概念。
在搭建MGR集群的时候,不允许集群中的各个节点个工作模式不一样。如果是单主模式,则所有的节点都是以单主模式启动。如果是多主模式,则所有节点都要以多主模式的配置来启动。控制单主和多主模式的参数是:
group_replication_single_primary_mode,当这个参数配置为on的时候,表示单主模式;当它的值为off的时候,表示多主模式。
单主模式示意图下:
多主模式示意图如下:
MGR集群的限制
- 存储引擎必须为Innodb,即仅支持InnoDB表,并且每张表一定要有一个主键,用于做write set的冲突检测;
- 每个表必须提供主键,没有主键的表不能在集群中正常插入和同步数据。
对一个没有主键的表,进行插入数据的时候,会有如下的错误信息:
mysql> show create table test\G
*************************** 1. row ***************************
Table: test
Create Table: CREATE TABLE `test` (
`id` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)
mysql> insert into test(id) values (1);
ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.
mysql>
- 只支持ipv4,网络需求较高,ipv6目前还不支持。
- 必须打开GTID特性,二进制日志格式必须设置为ROW,用于选主与write set。
- COMMIT可能会导致失败,类似于快照事务隔离级别的失败场景。
- 目前一个MGR集群组最多支持9个节点。
- 不支持外键于save point特性,无法做全局间的约束检测与部分部分回滚。
- 二进制日志binlog不支持Replication event checksums。这也是在配置文件中,为什么要把checksum参数设置为none的原因。
- 多主模式(也就是多写模式) 不支持SERIALIZABLE事务隔离级别。
- 多主模式不能完全支持级联外键约束。
- 主模式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务,后发起的事务会失败)。
环境准备
下面我们使用docker来部署多个MySQL数据库实例,然后用这些MySQL数据库实例来组建MGR单主模式的集群。我们计划部署3个MySQL数据节点,分别是为:master1、master2、master3。使用master1作为MGR单主模式集群的主节点。master2和master3作为secondary从节点。
Docker网段的准备
创建docker容器使用的网段
? ~ docker network create --subnet=172.22.0.0/24 mysql-ha-mgr-network
ff5db7a51bd5d72fce0e650bf1690cad8efd271e0248edde22f29ae0719f2faf
? ~
MySQL容器的启动
使用docker启动如下MySQL数据库容器,各个数据库的my.cnf配置文件,后面会贴出来。你也可以参考后面的配置文件后再启动以下容器。
# master1节点
docker run --net=mysql-ha-mgr-network --hostname master1.mysql --ip 172.22.0.11 --add-host "master2.mysql master2":172.22.0.22 --add-host "master3.mysql master3":172.22.0.33 --cap-add NET_ADMIN --name mysql-ha-mgr-master1 -d -v /Users/coder-home/docker_mysql_ha/mgr/master1:/etc/mysql/conf.d --privileged=true -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e MYSQL_ROOT_PASSWORD=root -e TZ="Asia/Shanghai" -p 33011:3306 mysql:5.7.31
# master2节点
docker run --net=mysql-ha-mgr-network --hostname master2.mysql --ip 172.22.0.22 --add-host "master1.mysql master1":172.22.0.11 --add-host "master3.mysql master3":172.22.0.33 --cap-add NET_ADMIN --name mysql-ha-mgr-master2 -d -v /Users/coder-home/docker_mysql_ha/mgr/master2:/etc/mysql/conf.d --privileged=true -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e MYSQL_ROOT_PASSWORD=root -e TZ="Asia/Shanghai" -p 33022:3306 mysql:5.7.31
# master3节点
docker run --net=mysql-ha-mgr-network --hostname master3.mysql --ip 172.22.0.33 --add-host "master1.mysql master1":172.22.0.11 --add-host "master2.mysql master2":172.22.0.22 --cap-add NET_ADMIN --name mysql-ha-mgr-master3 -d -v /Users/coder-home/docker_mysql_ha/mgr/master3:/etc/mysql/conf.d --privileged=true -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e MYSQL_ROOT_PASSWORD=root -e TZ="Asia/Shanghai" -p 33033:3306 mysql:5.7.31
--add-host "master1.mysql master1":172.22.0.11:增加这个参数的目的是为了解决docker容器在重启之后,修改后的hosts文件被还原的问题,这样在启动容器后,host文件都会按照这个配置修改好。
MGR插件的安装
MGR安装方式一
MGR作为一个插件提供,需要我们自己所有的MySQL集群节点中手动的安装它们,他们的安装文件在我们按照MySQL数据库服务的时候已经写在了插件目录下。如下所示:
mysql> show variables like '%dir%';
+-----------------------------------------+----------------------------+
| Variable_name | Value |
+-----------------------------------------+----------------------------+
| basedir | /usr/ |
| binlog_direct_non_transactional_updates | OFF |
| character_sets_dir | /usr/share/mysql/charsets/ |
| datadir | /var/lib/mysql/ |
/* ............省略输出............. */
| lc_messages_dir | /usr/share/mysql/ |
| plugin_dir | /usr/lib/mysql/plugin/ |/* 插件安装文件所在的目录 */
| slave_load_tmpdir | /tmp |
| tmpdir | /tmp |
+-----------------------------------------+----------------------------+
15 rows in set (0.00 sec)
mysql>
安装MGR插件的命令如下,以下安装命令要在所有的MySQL数据库节点都执行一次。
mysql> install plugin group_replication soname 'group_replication.so';
Query OK, 0 rows affected (0.06 sec)
mysql>
在各个节点,查看安装完成MGR插件之后的结果如下所示,前面省略输出其他无关内容,只贴出我们关心的内容。
mysql> show plugins;
+----------------------------+----------+--------------------+----------------------+---------+
| Name | Status | Type | Library | License |
+----------------------------+----------+--------------------+----------------------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
/* 省略输出 */
| ngram | ACTIVE | FTPARSER | NULL | GPL |
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |/* 这里就是我们安装后的插件 */
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)
mysql>
MGR安装方式二
除了在MySQL运行的过程中安装MGR插件,还可以在MySQL的my.cnf配置文件中增加如下的配置来启用MGR插件,效果等同于上面使用plugin install命令安装的操作。
[mysqld]
plugin_load_add='group_replication.so'
MGR集群的配置
修改主机hosts文件
在所有的MySQL节点的主机中,修改host配置文件。增加如下主机IP地址和主机名称的映射关系。如果在确定容器的时候,已经制定的所有主机的IP地址和主机名称的映射,可以跳过这个修改host文件的操作。
172.22.0.11 master1.mysql master1
172.22.0.22 master2.mysql master2
172.22.0.33 master3.mysql master3
如果不做主机名称和IP映射这一步,在启动MGR组复制之后,可能会出现新键入的节点都处于RECOVERING的状态,如下所示:
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | d8bc7fba-816c-11eb-b2c9-0242ac16000b | master1.mysql | 3306 | ONLINE |
| group_replication_applier | db7202e2-816c-11eb-b5f5-0242ac160016 | master2.mysql | 3306 | RECOVERING |
| group_replication_applier | de22c095-816c-11eb-97b2-0242ac160021 | master3.mysql | 3306 | RECOVERING |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)
修改my.cnf配置文件
配置MySQL的my.cnf配置文件,用于配置MGR复制的功能。具体配置如下:
maser1节点的配置文件如下所示:
[mysqld]
# 数据库全局唯一ID表示
server-id=11
# 设置binlog的格式
binlog_checksum=NONE
binlog_format=row
binlog_row_image=minimal
# 设置数据库默认的字符集编码
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
# 开启GTID的功能
enforce_gtid_consistency=on
gtid_mode=on
innodb_rollback_on_timeout=on
# 开启binlog
log-bin=master1-mysql-bin
log_slave_updates=on
relay_log_purge=off
# MGR参数配置
plugin_load_add='group_replication.so'
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="0b7fac73-0413-41bf-b197-210da2a5c024"
loose-group_replication_group_seeds="172.22.0.11:33061,172.22.0.22:33061,172.22.0.33:33061"
loose-group_replication_local_address="172.22.0.11:33061"
loose-group_replication_single_primary_mode=on
loose-group_replication_start_on_boot=off
loose-group_replication_bootstrap_group=off
loose-group_replication_ip_whitelist='172.22.0.1/24'
loose-group_replication_member_weight=90
# 日志和组从同步复制信息存储方式
master_info_repository=TABLE
relay_log_info_repository=TABLE
# 开启逻辑时钟
slave-preserve-commit-order=on
slave_parallel_type='logical_clock'
slave_parallel_workers=6
# 开启慢查询日志
slow_query_log=ON
slow_query_log_file=/var/lib/mysql/master1-slow.log
master2节点配置文件如下所示:
[mysqld]
binlog_checksum=NONE
binlog_format=row
binlog_row_image=minimal
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
enforce_gtid_consistency=on
gtid_mode=on
log-bin=master2-mysql-bin
log_slave_updates=on
loose-group_replication_bootstrap_group=off
loose-group_replication_group_name="0b7fac73-0413-41bf-b197-210da2a5c024"
loose-group_replication_group_seeds="172.22.0.11:33061,172.22.0.22:33061,172.22.0.33:33061"
loose-group_replication_local_address="172.22.0.22:33061"
loose-group_replication_single_primary_mode=on
loose-group_replication_start_on_boot=off
loose-group_replication_ip_whitelist='172.22.0.1/24'
loose-group_replication_member_weight=90
master_info_repository=TABLE
plugin_load_add='group_replication.so'
read_only=on
relay-log=mysql-relay
relay_log_info_repository=TABLE
relay_log_purge=off
server-id=22
slave-preserve-commit-order=on
slave_parallel_type='logical_clock'
slave_parallel_workers=6
transaction_write_set_extraction=XXHASH64
master3节点配置文件如下所示:
[mysqld]
binlog_checksum=NONE
binlog_format=row
binlog_row_image=minimal
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
enforce_gtid_consistency=on
gtid_mode=on
log-bin=master3-mysql-bin
log_slave_updates=on
loose-group_replication_bootstrap_group=off
loose-group_replication_group_name="0b7fac73-0413-41bf-b197-210da2a5c024"
loose-group_replication_group_seeds="172.22.0.11:33061,172.22.0.22:33061,172.22.0.33:33061"
loose-group_replication_local_address="172.22.0.33:33061"
loose-group_replication_single_primary_mode=on
loose-group_replication_start_on_boot=off
loose-group_replication_ip_whitelist='172.22.0.1/24'
loose-group_replication_member_weight=50
master_info_repository=TABLE
plugin_load_add='group_replication.so'
read_only=on
relay-log=mysql-relay
relay_log_info_repository=TABLE
relay_log_purge=off
server-id=33
slave-preserve-commit-order=on
slave_parallel_type='logical_clock'
slave_parallel_workers=6
transaction_write_set_extraction=XXHASH64
以上针对三个MySQL数据库实例的my.cnf配置文件的修改是为了配置MGR集群而增加了MGR配置。在修改完成上面的配置文件之后,可以重启三个MySQL数据库容器,以便修改生效。
对于MGR组复制相关的参数前带有loose-关键字的目的是如果MySQL不支持这个参数,可以忽略这个参数的配置。如果支持,则使用这个参数的配置。起到兼容的目的。
下面针对每一个关于MGR相关的参数做简要的说明:
- group_replication_group_name:MySQL组复制的组名称,它的值一个32位的UUID,可以配置为任何一个UUID,但是同一个MGR集群中要是配置相同的UUID,才会成为同一个MGR集群。如果你需要配置2个MGR集群,则需要使用2个不同的UUID,每个MGR集群一个。在组复制中,binlog中记录的GTID是使用这个UUID来进行构造的。我们可以通过如下两种方式来得到一个UUID:
# 在MySQL数据库服务上执行如下命令
cat /proc/sys/kernel/random/uuid
/* 在MySQL命令行终端执行如下命令 */
select uuid();
- plugin_load_add:启动MGR组复制插件,这样启动的MySQL数据库就不需要进入到里面手动的安装MGR复制的插件了,推荐使用这一种方式来安装MGR插件。
- transaction_write_set_extraction:指示Server必须为每个事务收集写集合,并使用XXHASH64哈希算法将其编码为散列。
- group_replication_local_address:本机的IP地址和端口号,格式为ip:port或host:port,端口号是用来MGR集群中各个节点通讯用的端口号,不是MySQL数据库服务的3306端口。MGR集群中各个节点之间的通讯,就是通过这个IP和端口来进行通讯。
- group_replication_group_seeds:设置种子节点的IP地址和端口号。当前有新节点加入到集群的时候,可以这些种子节点进行同步数据。这里可以配置任意多个已经存在的节点IP地址和端口,不一定要把所有节点的IP地址和端口都配置在这里。
- group_replication_single_primary_mode:MGR集群的单主或多主模式的开关,若为on,表示单主模式,集群中只有一个节点提供写服务,如果是off,表示多主模式,所有节点都可以提供写服务。推荐使用单主模式,因为多主模式写也要保住每一个写入请求的事务都要同步到所有节点之后才可以返回成功。这个和单主模式下面的写请求对效率的提升并没有任何提高,反而在多主模式下,容易产生回滚事务的操作。这个参数在集群中所有节点都要一致,不能既有on又有off,并且,集群运行的过程中这个参数不能修改。如果要修改需要把集群全部停止后才可以修改。
- group_replication_start_on_boot:是否在MySQL启动的时候就启动MGR组复制功能。在第一次搭建MGR集群的时候,所有节点都不要配置为on,在搭建好MGR之后,可以在把所有节点配置文件中的这个参数改为on。这样在下次重启MySQL数据库服务的时候,就会自动开启MGR组复制功能。但是单主模式下要求启动的顺序是主节点先启动,然后从节点再启动,这样从节点才会自动加入到MGR集群中。
- group_replication_bootstrap_group:配置该节点是否为引导节点。MGR集群中,第一个加入到MGR集群的节点,称为引导组节点。这个参数在任何一个节点都要设置为off,只有在第一个加入到MGR集群的节点上,在命令行中,手动的使用set group_replication_bootstrap_group = on;然后开启MGR集群,接的启动MGR集群后,再次将这个参数设置为off。如果在多个节点上面都开启这个参数,容易产生脑裂的现象。
- group_replication_member_weight:取值范围为[0,100],默认值为50。这个参数用于标识当前节点在主节点宕机之后,成为新的主节点的权重。改值越大,标识越有可能成新的主节点。当我们希望某些节点称为候选主节点时候,可以通过这个参数来控制希望哪个节点称为新的主。
- group_replication_ip_whitelist:可以加入到当前MGR集群的MySQL的IP地址白名单。如果增加到了这个参数,就表示只有IP地址在这个白名单的范围内的MySQL数据库才可以加入到当前MGR集群,否则不能加入。
- group_replication_auto_increment_increment:在MGR集群中,表的自增键值,每次增加的步长值是多少。默认为7。
更多参数详见官网:Group Replication System Variables
MGR集群的启动
在初始化启动MGR集群的时候,需要先初始化MGR集群的第一个节点,此时的这个节点就是MGR集群的主节点,然后其他节点在一个个加入到集群中,称之为从节点。可以参考如下命令来初始化第一个节点:
set sql_log_bin=0; /* 以下操作不记录到binlog日志文件中 */
create user 'repl'@'172.22.0.%' identified by 'repl';
grant replication slave on *.* to 'repl'@'172.22.0.%';
set sql_log_bin=1; /* 以下操作会记录到binlog日志文件中 */
change master to master_user='repl', master_password='repl' for channel 'group_replication_recovery';
set global group_replication_bootstrap_group=on; /* 只需要在第一个初始化节点上执行,其他从节点不需要执行 */
start group_replication; /* 启动主节点组复制功能 */
set global group_replication_bootstrap_group=off; /* 只需要在第一个初始化节点上执行,其他从节点不需要执行 */
select * from performance_schema.replication_group_members; /* 查看MGR集群节点状态 */
如果有其他节点需要加入到集群中,则在其他节点上执行如下命令来加入到已经启动的MGR集群中。此时不需要修改
group_replication_bootstrap_group参数了,这个参数只有在第一次初始化MGR集群的时候才需要设置为on,其他节点加入则不需要修改这个参数。命令参考如下:
set sql_log_bin=0; /* 以下操作不记录到binlog日志文件中 */
create user 'repl'@'172.22.0.%' identified by 'repl';
grant replication slave on *.* to 'repl'@'172.22.0.%';
set sql_log_bin=1; /* 以下操作会记录到binlog日志文件中 */
change master to master_user='repl', master_password='repl' for channel 'group_replication_recovery';
set global group_replication_allow_local_disjoint_gtids_join=on; /* 查看MySQL的错误日志/var/log/mysql/error.log,来决定是否需要执行这个语句 */
start group_replication; /* 启动从节点组复制功能 */
select * from performance_schema.replication_group_members; /* 查看MGR集群节点状态 */
创建MySQL组复制使用的账号的目的是用于MGR集群中的数据复制。这个账号需要在所有的MGR节点都创建。并且创建的时候,记得要把binlog记录日志的功能暂时关闭,这样可以避免这个数据库账号被同步到其他节点而发生错误。创建账号的命令需要在我们的master1、master2、master3三个节点上都执行。
当然,如果在初始化集群的时创建复制用户时没有将sql_log_bin关闭,那么在新节点中就不需要执行创建复制用户这个步骤,因为这个用会被同步到新的数据库节点中。
master1节点的初始化
我们此时选择在master1节点作为MGR集群的第一个初始化节点,这也就是主节点。第一个节点初始化命令参考如下:
set sql_log_bin=0; /* 以下操作不记录到binlog日志文件中 */
create user 'repl'@'172.22.0.%' identified by 'repl';
grant replication slave on *.* to 'repl'@'172.22.0.%';
set sql_log_bin=1; /* 以下操作会记录到binlog日志文件中 */
change master to master_user='repl', master_password='repl' for channel 'group_replication_recovery';
set global group_replication_bootstrap_group=on; /* 只需要在第一个初始化节点上执行,其他从节点不需要执行 */
start group_replication; /* 启动主节点组复制功能 */
set global group_replication_bootstrap_group=off; /* 只需要在第一个初始化节点上执行,其他从节点不需要执行 */
select * from performance_schema.replication_group_members;
master1节点,初始化过程如下:
mysql> set sql_log_bin=0; /* binlog */
Query OK, 0 rows affected (0.00 sec)
mysql> create user 'repl'@'172.22.0.%' identified by 'repl';
Query OK, 0 rows affected (0.00 sec)
mysql> grant replication slave on *.* to 'repl'@'172.22.0.%';
Query OK, 0 rows affected (0.00 sec)
mysql> set sql_log_bin=1; /* binlog */
Query OK, 0 rows affected (0.00 sec)
mysql> change master to master_user='repl', master_password='repl' for channel 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)
mysql>
mysql> select * from performance_schema.replication_group_members;
+---------------------------+-----------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+-----------+-------------+-------------+--------------+
| group_replication_applier | | | NULL | OFFLINE |
+---------------------------+-----------+-------------+-------------+--------------+
1 row in set (0.00 sec)
mysql> set global group_replication_bootstrap_group=on;
Query OK, 0 rows affected (0.01 sec)
mysql> start group_replication;
Query OK, 0 rows affected (2.10 sec)
mysql> set global group_replication_bootstrap_group=off;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | f6d7f63b-8314-11eb-b9ab-0242ac16000b | master1.mysql | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
1 row in set (0.00 sec)
mysql> select @@hostname;
+---------------+
| @@hostname |
+---------------+
| master1.mysql |
+---------------+
1 row in set (0.00 sec)
mysql>
master2节点加入MGR集群
参考如下命令来启动master2节点:
set sql_log_bin=0; /* 以下操作不记录到binlog日志文件中 */
create user 'repl'@'172.22.0.%' identified by 'repl';
grant replication slave on *.* to 'repl'@'172.22.0.%';
set sql_log_bin=1; /* 以下操作会记录到binlog日志文件中 */
change master to master_user='repl', master_password='repl' for channel 'group_replication_recovery';
set global group_replication_allow_local_disjoint_gtids_join=on;
start group_replication;
select * from performance_schema.replication_group_members;
master2节点,加入MGR集群的过程如下:
mysql>
mysql> set sql_log_bin=0; /* binlog */
Query OK, 0 rows affected (0.00 sec)
mysql> create user 'repl'@'172.22.0.%' identified by 'repl';
Query OK, 0 rows affected (0.01 sec)
mysql> grant replication slave on *.* to 'repl'@'172.22.0.%';
Query OK, 0 rows affected (0.00 sec)
mysql> set sql_log_bin=1; /* binlog */
Query OK, 0 rows affected (0.00 sec)
mysql> change master to master_user='repl', master_password='repl' for channel 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.03 sec)
mysql>
mysql>
mysql> start group_replication;
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.
mysql> set global group_replication_allow_local_disjoint_gtids_join=on;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql>
mysql> start group_replication;
Query OK, 0 rows affected, 1 warning (4.89 sec)
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | f6d7f63b-8314-11eb-b9ab-0242ac16000b | master1.mysql | 3306 | ONLINE |
| group_replication_applier | fc12506a-8314-11eb-8d57-0242ac160016 | master2.mysql | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
2 rows in set (0.00 sec)
mysql> select @@hostname;
+---------------+
| @@hostname |
+---------------+
| master2.mysql |
+---------------+
1 row in set (0.00 sec)
mysql>
master3节点加入MGR集群
参考master2节点加入的方式,在master3上执行如下命令:
set sql_log_bin=0; /* 以下操作不记录到binlog日志文件中 */
create user 'repl'@'172.22.0.%' identified by 'repl';
grant replication slave on *.* to 'repl'@'172.22.0.%';
set sql_log_bin=1; /* 以下操作会记录到binlog日志文件中 */
change master to master_user='repl', master_password='repl' for channel 'group_replication_recovery';
set global group_replication_allow_local_disjoint_gtids_join=on;
start group_replication;
select * from performance_schema.replication_group_members;
master3节点,加入MGR集群的过程如下:
mysql> set sql_log_bin=0; /* binlog */
Query OK, 0 rows affected (0.00 sec)
mysql> create user 'repl'@'172.22.0.%' identified by 'repl';
Query OK, 0 rows affected (0.01 sec)
mysql> grant replication slave on *.* to 'repl'@'172.22.0.%';
Query OK, 0 rows affected (0.00 sec)
mysql> set sql_log_bin=1; /* binlog */
Query OK, 0 rows affected (0.00 sec)
mysql> change master to master_user='repl', master_password='repl' for channel 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)
mysql> set global group_replication_allow_local_disjoint_gtids_join=on;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> start group_replication;
Query OK, 0 rows affected, 1 warning (3.37 sec)
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | f6d7f63b-8314-11eb-b9ab-0242ac16000b | master1.mysql | 3306 | ONLINE |
| group_replication_applier | fc12506a-8314-11eb-8d57-0242ac160016 | master2.mysql | 3306 | ONLINE |
| group_replication_applier | fff4ee75-8314-11eb-a636-0242ac160021 | master3.mysql | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)
mysql> select @@hostname;
+---------------+
| @@hostname |
+---------------+
| master3.mysql |
+---------------+
1 row in set (0.00 sec)
mysql>
未完待续...