MYSQL集群

MYSQL集群

主从复制实验
1.将主从节点的防火墙全部关闭 ，安装数据库
2.在/etc/hosts 里添加两侧主机的IP和主机名（选做）

192.168.100.80	mysql8
192.168.100.81	mysql8b

3.先让所有的mysql数据库的UUID保持不同（如果你时直接复制的安装好的mysql的虚拟机，那么每个虚拟机上搭载的mysql数据库UUID是一致的）

vi /data/mysql_data/auto.cnf
查看不同主机的UUID，修改相同的UUID

4.主节点参数修改

vi /etc/my.cnf
在里面添加
#MASTER-SLAVE
#主节点的server-id，集群中的每一台服务器的server-id都不允许相同
server-id = 1
#需要复制的库
binlog-do-db = hr
#binlog-do-db = hr1
#不需要复制的库
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
binlog-ignore-db=performance_schema
binlog-ignore-db=sys
#binlog日期过期天数设置
#expire_logs_day=7

5.重启数据库服务

service mysqld restart;

6.创建复制用户(主库)

GRANT ALL PRIVILEGES ON *.* TO 'rel'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
FLUSH PRIVILEGES;

7.从节点参数配置

server-id = 2
#设置从库只读状态，避免在从库上写操作，但是该指令对超级管理员是无效的，mysql5.7增加了一个新的参数super_read_only,该参数使得超级管理员也是无法进行写操作。但是super_read_only这个参数大部分都是关闭掉的。
read_only = 1
#super_read_only = 1
#中继日志后缀名，默认host_name-relay-bin.index，在datadir目录下
relay-log-index=slave-relay-bin.index
#中转（中继）日志文件前缀名，也是默认在datadir目录下
relay-log=slave-relay-bin
#把master.info（主从状态，配置信息）记录下来，默认记录搭配file里面，建议使用表记录
master_info_repository=TABLE
#用来决定slave同步的位置信息记录在哪里，同样有两个参数。
#如果relay_log_info_repository=file,就会创建一个relay-log.info,如果relay_log_info_repository=table,就会创建mysql.slave_relay_info表来记录同步的位置信息
relay_log_info_repository=TABLE
#禁止写操作
#relay_log_recovery=1

保存退出，重启mysql数据库。

8.获取主库状态信息

show master status\G;

9.从库安照主机给出的信息进行修改（mysql服务端执行）

change master to master_host='192.168.100.57',master_port=3306,

MYSQL主从复制集群

官方：mysql内建的复制功能是构建大型，高性能应用程序的基础。将mysql的数据分布到多个系统上去，这种分布的机制，是通过将mysql的某一台主机的数据复制到其他主机上，并重新执行一边来实现的。复制过程中一个服务器充当主服务器，而一个或多个其他服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接受那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。
注意：当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。

数据量上来以后会造成的问题
1.单机->集群
随着数据量的增大，读写并发的增加，系统可用性要求的提升，单机mysql出现危机：
容量问题，难以扩容，考虑数据库拆分，分库分表
读写压力，QPS过大，特别是分析类需求会影响到业务事务，考虑多机集群，主从复制高可用性不足，以宕机，考虑故障转移，MHA/MGR等。
高峰时数据库连接数经常超过上限

为什么要读写分离？
高并发场景下mysql的一种优化方案，依靠主从复制使得mysql实现了数据复制为多份，增强了抵抗高并发读写请求的能力，提升了mysql查询性能的同时，也提升了数据的安全性。当某一个mysql节点，无论是主库还是从库故障时，还有其他节点中存储着全量数据，保证数据不会丢失。
主库将变更写binlog日志，然后从库连接主库后，从库有个IO线程，将主库的binlog日志拷贝到本地，写入一个中继日志，接着从库中有一个sql线程会从中继日志中读取binlog，然后执行binlog日志中的内容。即在本地再次执行一边sql，确保根主库的数据相同。
简单点说：读写分离的实现基于主从复制架构：一主多从，只写主库，主库会自动将数据同步到从库。

mysql复制技术有以下一些特点：
（1）数据分布
（2）负载平衡
（3）备份
（4）高可用性和容错行

mysql支持的复制类型：
1）基于语句的复制statement：在主副服务器上执行的sql语句，在从服务器上执行同样的语句。mysql默认采用基于语句的复制，效率比较高。一旦发现没法精确复制时，会自动选择基于行的复制。
2）基于行的复制row：把改变的内容复制过去，而不是把命令在从服务器上执行一遍，从mysql5.0开始支持。
3）混合类型的复制mixed：默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制
具体基于哪种类型其实还是要看你的binlog日志类型。

mysql主从复制集群种类：
双主复制：双主复制，也就是可以互做主从复制，每个master即是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另一方的数据库中。
级联复制：级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3-5个从几点连接主节点，其他从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。

mysql主从复制原理：
1）slave上面的IO线程连接上master，并请求从指定日志文件（二进制日志）的指定位置（或者从最开始的日志）之后的日志内容。
2）master接收到来自slave的IO线程的请求后，通过负责复制的IO线程根据请求信息读取指定日志指定位置之后的日志信息，返回给slave端的IO线程。
返回信息中除了日志包含的信息之外，还包括本次返回的信息在master端的binlog日志文件的名称以及在binlog中的位置。
3）slave的IO线程接收到信息后，将接收到的日志内容依次写入到slave端的relaylog（中继日志）文件的最末端，并将读取到的master端的binlog的文件名和位置记录到master-info文件中，
以便在下一次读取的时候能够清楚的告诉master“我需要从某个binlog的哪个位置开始往后的日志内容，请发给我”。
4）slave的sql线程检测到relaylog中新增加了内容后，会马上解析该log文件中的内容成为在master端真实执行时候的那些可执行的query语句，并在自身执行这些query。
这样，实际上就是在master端和slave端执行了同样的query，所以两端的数据完全一样的。
简单的说明：
1）mysql的replication是一个异步的复制过程，从一个mysql实例复制到另一个mysql实例。
在master与slave之间的实现整个复制过程主要由三个线程来完成，其中两个线程（sql线程和IO线程）在slave端，另一个线程（IO线程）在Master端。
2）在执行这个主从复制之前，首先必须打开master端的binlog功能，否则无法实现。
在启动mysql server的过程中使用”log-bin“参数选项
在my.cnf配置文件中的mysql参数组中增加“log-bin”参数项

几种复制模式：
异步复制：经典的主从复制，Primary-Secondary Replication，2000年mysql3.23.15版本引入replication。
逻辑上mysql默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接收并处理，这样会有一个问题，主库如果崩溃了，此时主库上已经提交的事务可能并没有传到从库上，如果此时，强行将从库提升为主库，可能导致新主库的数据不完整。
技术上主库将事务binlog时间写入到binlog文件中，此时主库只会通知一下bump线程发送这些新的binlog，然后主库就会继续处理提交操作，而此时不会保证这些binlog传到任何一个从库节点上。

同步复制：逻辑上指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会接收到严重的影响。

技术上当主库提交事务之后，所有的从库节点必须收到并且提交这些事务，然后主库线程才能继续做后续操作。素虽然安全但是缺点是，主库完成一个事务的时间会被拉长，性能降低。

半同步复制：逻辑上是介于全同步复制与异步复制之间的一种，主库只需要等待至少一个从库节点收到并刷新binlog到relaylog文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经玩群并且提交的反馈，如此，节省了很多时间。
技术上节育异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relaylog中才返回给客户端。相对于异步复制，半同步复制提高可数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以半同步复制最好在低延迟时的网络中使用。

Replication管理和排错
1）show master status;查看master的状态，尤其是当前的日志及位置
2）show slave stats;查看slave的状态
3）reset slave（all）; 充值slave状态，用于删除slave数据库的relaylog日志文件并重新启用新的relaylog文件，会忘记主从关系，它删除master.info文件和relay-log.info文件。
4）start slave; 启用slave状态（开始舰艇master的变化）
5）stop slave;暂停slave状态；
6）set global sql_slave_skip_counter = n 跳过导致复制终止的n个时间，仅在slave线程没运行的状况下使用。

主从复制-一主多从（M-S-S）

这里采用一个主库 一个slave 中继库 一个slave从库的方式去实现这种集群架构，中继库和从库其实都可以查询到数据。

环境：
192.168.100.57 	mysql57		主库
192.168.100.58 	mysql57b	slave中继库
192.168.100.59 	mysql57c	slave库
主库参数配置如下：
在my.cnf文件中添加以下内容
server-id=1
binog-do-db=hr
#binlog-do-db=
binlog-ignore-db=mysql
binlog-ignore-db=infomation_schema
binlog-ignore-db=performance_schema
binlog-ignore-db=sys
#expire_logs_days=7
sync-binlog=1
保存退出，重启数据库
service mysqld restart
--创建用户（主库）
GRANT replication slave ON *.* TO 'repl'@'%'IDENTIFIED BY '123456' WITH GRANT OPTION
FLUSH PRIVILEGES;

sync-binlog参数来控制数据库的binlog刷到磁盘上去，sync_binlo=0,表示mysql不控制binlog的刷新，由文件系统自己控制它的缓存的刷新，这时候的性能是最好的，但是风险是最大的，因为一旦系统crash，在binlog_cache中的所有binlog信息逗户丢失。
sync-binlog>0,表示每次sync-binlog次事务提交，mysql调用文件系统的刷新操作将缓存刷下去。
sync-binlog=1,表示每次事务提交，mysql都会把binlog刷下去，是最安全但是性能损耗最大的设置。

SLAVE中继库配置

在 my.cnf文件中添加以下内容：
server-id=2
#修改主配置文件也要开启bin-log
#log-bin=mysql-bin-slave1	如果已经开启binlog请忽略此参数
log-slave-updates=1
#binlog-format=row	如果已经设置请忽略
保存，重启数据库
service mysqld restart;

--指定中继slave的主服务器
stop slave;
change master to master_host='192.168.100.57',master_user='repl',master_password='123456';
start slave;
--查看中继库的状态
show slave status	\G;
--在中继库中建立复制用户
GRANT replication slave ON *.* TO 'repl'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
FLUSH PRIVILEGES;

参数解释
log-slave-updates=1 把它从relay-log当中读取出来的二进制日志并且连带着本机上执行的操作也记录到二进制日志里面，这样才能使得第三台slave通过 中继slave读取到相应数据变化。

最终在slave数据库上操作

在my.cnf中添加
server-id=3
#log-bin=mysql-bin-slave2 如果已经开启binlog请忽略
#binlog-format=row	如果已经设置请忽略此参数
read-only=1
#super_read_only=1
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
master_info_repository=TABLE
relay_log_info_repository=TABLE
#relay_log_recovery=1
保存重启数据库
在数据库中执行
stop slave;
reset slave;
change master to master_host='192.168.100.58',master_user='repl',master_password='123456';
start slave;
--查看从库的状态
show slave status \G;

--如果出现以下问题，或者你的show slave status \G也出现什么东西无法跳过的话，可以使用下面的解决方案
last_sql_error:error 'Unknown table 'hr.ts123'' on query. Default database:''.Query:'DROP TABLE `hr`.`ts123`/* generated by server */'
解决方案：
select @@sql_slave_skip_counter;
stop slave; --或者stop slave sql_thread 
set global sql_slave_skip_counter = 1;
--重启slave
start slave;

参数详解：
SQL_SLAVE_SKIP_COUNTER
1.主从复制时从库复制中断，一般造成的原因如主键冲突；对应的表或者库不存在；drop操作的表不存在；基于row复制时，操作的行不存在；
常常大家会通过使用set global SQL_SLAVE_SKIP_COUNTER = n 来跳过导致复制错误的SQl。
2.使用sql_slave_skip_counter 跳过，每一个跳过为一个binlog event group ，也就相当于一个事务。所以当第一个事务中有两个sql，第一个sql导致主从复制中断，然后我们直接使用sql_slave_skip_counter=1跳过错了，所以我们在跳过之前，一定要看一下，当前binlog event group到底是什么，或者根据从库报错信息判断。

一主多从复制

--master
server-id=1
binlog-do-db=hr
binlog-ignore-db=mysql
binlog-ignore-db=information
binlog-ignore-db=permance_schema
binlog-ignore-db=sys
#expire_logs_days=7

保存重启mysql

--建立一个复制用户
GRANT replication slave ON *.* TO 'repl'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
flush privileges;
--查看master状态，给到从库
show master status;

配置从库1

--在my.cnf中添加
server-id=2
read-only=1
#super_read_only=1
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
master_info_repository=TABLE
relay_indep_repository=TABLE
#relay_log_recover=1
保存重启mysql
service mysqld restart;
--从库按照主库给出的信息修改(在mysql客户端修改)
change master to master_host='192.168.100.57',master_port=3306,master_user='repl',master_password='123456',master_log_file='mysql-bin-3306.000122',master_log_pos=607;
--重启slave
start slave;
show slave status;

配置从库2

--在my.cnf中添加
server-id=3
read-only=1
#super_read_only=1
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
master_info_repository=TABLE
relay_indep_repository=TABLE
#relay_log_recover=1
保存重启mysql
service mysqld restart;
--从库按照主库给出的信息修改(在mysql客户端修改)
change master to master_host='192.168.100.57',master_port=3306,master_user='repl',master_password='123456',master_log_file='mysql-bin-3306.000122',master_log_pos=607;
--重启slave
start slave;
show slave status;

配置多主一从

配置master1

--master1
server-id=1
binlog-do-db=hr
binlog-ignore-db=mysql
binlog-ignore-db=information
binlog-ignore-db=permance_schema
binlog-ignore-db=sys
#expire_logs_days=7

保存重启mysql

--建立一个复制用户
GRANT replication slave ON *.* TO 'repl'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
flush privileges;
--查看master状态，给到从库
show master status;

配置master2

--master2
server-id=2
binlog-do-db=test
binlog-ignore-db=mysql
binlog-ignore-db=information
binlog-ignore-db=permance_schema
binlog-ignore-db=sys
#expire_logs_days=7

保存重启mysql

--建立一个复制用户
GRANT replication slave ON *.* TO 'repl'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
flush privileges;
--查看master状态，给到从库
show master status;

配置从库slave

--在my.cnf中添加
server-id=3
read-only=1
#super_read_only=1
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
master_info_repository=TABLE
relay_indep_repository=TABLE
#relay_log_recover=1
保存重启mysql
service mysqld restart;
--从库按照主库给出的信息修改(在mysql客户端修改)
change master to master_host='192.168.100.57',master_port=3306,master_user='repl',master_password='123456',master_log_file='mysql-bin-3306.000122',master_log_pos=607 for channel 'master_1';
change master to master_host='192.168.100.58',master_port=3306,master_user='repl',master_password='123456',master_log_file='mysql-bin-3306.000133',master_log_pos=799 for channel 'master_2';
--重启slave
start slave;
show slave status;

参数：
for channel ‘xxxxxx’
当你要进行M-S-M，多主一从同步复制的时候，为了避免在从库中后执行的主库同步信息，将先执行的主库同步信息覆盖的这种情况，所以就要使用 for channel 参数，将这两个同步信息放到不同的管道中在从库中进行配置，‘xxxx’参数是你起的管道名称，两个不能一样，要不就成一条管道了，还是覆盖。

主主复制-MASTER-MASTER

master1

--192.168.100.57
在主库中my.cnf文件中添加
server-id=1
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
master_info_repository=TABLE
relay_log_info_repository=TABLE
auto_increment_increment=2
auto_increment_offset=1
保存，重启mysql服务
--建立复制用户
GRANT replication slave ON *.* TO 'repl'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
FLUSH PRIVILEGES;
--获取主机信息，给从库
show master status;
--根据获取的master2的信息修改master1
change master to 
master_host='192.168.100.58',master_port=3306,master_user='repl',master_password='123456',master_log_file='mysql-bin-3306.000129',master_log_pos=617;

--重启slave
start slave;

--获取从库信息
show slave status;

master2

--192.168.100.58
在主库中my.cnf文件中添加
server-id=2
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
master_info_repository=TABLE
relay_log_info_repository=TABLE
auto_increment_increment=2
auto_increment_offset=2
保存，重启mysql服务
--建立复制用户
GRANT replication slave ON *.* TO 'repl'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
FLUSH PRIVILEGES;
--获取主机信息，给从库
show master status;
--根据获取的master1的信息修改master2
change master to 
master_host='192.168.100.57',master_port=3306,master_user='repl',master_password='123456',master_log_file='mysql-bin-3306.000133',master_log_pos=799;

--重启slave
start slave;

--查看从库信息
show slave status;

注意：两边库都要做双主复制，所以关于复制库的参数就可以不用配置了。
master1和master2直邮server-id和auto_increment_offset的值不同。mysql中有自增长字段，数据库的主主同步需要设置自增长的两个相关配置。
auto_increment_increment:表示字段每次递增的量，其默认值是1。它的值应设为整个结构中服务器的总数，本例用到2个服务器，所以设置为2.
auto_increment_offset:设定数据库中自动增长的起点（即初始值），因为两台服务器都设定了一次自动增长值2，所以他们的起点必须不同，才能避免两台服务器的数据在同步时出现的主键冲突。

MYSQL8.0主从复制

master配置

--在my.cnf中添加
server-id=1
binlog-do-db=hr
#binlog-do-db=hr2
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
binlog-ignore-db=performance_schema
binlog-ignore-db=sys
#expire_logs_days=7
保存，重启mysql
service mysqld restart;
--在mysql客户端下执行
--创建复制用户(创建用户的方式发生了变化)
-- 为了杜绝mysql8的密码验证新特性，所以我们在mysql主从复制集群中，或者其他类型场合，在建立相关用户时应该这么做，但是希望大家root用户还是用传统的模式，因为要考虑到系统的安全度。
CREATE USER 'repl'@'%' IDENTIFIED  BY '123456';
ALTER USER 'repl'@'%' IDENTIFIED WITH sha256_password BY '123456';
GRANT ALL PRIVILEGES ON *.* TO 'repl'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

--查看master的状态
show master status;

slave配置

在my.cnf中添加
server-id=2
read-only=1
#super_read_only = 1
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
master_info_repository=TABBLE
relay_log_info_repository=TABLE
#relay_log_recovery=1
保存，重启mysql
service mysqld restart;
show slave status \G;

--如果报错
message:Authention  plugin"caching_sha2_password" reported error: Authention requires secure connection.
--使用下面的方法解决（从属节点）
stop group_replication;
set global group_replication_recovery_get_public_key=on;
start group_replication;
该参数说明：在安全状态下把主机的public_key同步到从机上
或使用下列语句去解决：
SET SQL_LOG_BIN=0;--不记录binlog日志
ALTER USER 'repl'@'%' IDENTIFIED WITH sha256_password BY '123456'; 
SET SQL_LOG_BIN=1;--记录binlog日志
--如果出现了 Last_SQL_Error:'Operation AlTER USER failed 'repl'@'%' on query. Default database:''.Query:'ALTER USER 'repl'@'%'IDENTIFIED WITH 'sha256_password' AS '$5$=T*.GPKZCX(WFFFGG''
解决方案：
select @@sql_slave_skip_counter;
stop slave;或者 stop slave sql_thread;
set global sql_slave_skip_counter=1;
start slave;

show slave status;

--在mysql客户端下执行
change master to master_host='',master_port=3306,master_user='repl',master_password='123456',master_log_file='mysql-bin-3306.000022',master_log_pos=1889;

MYSQL8.0 MGR集群搭建

1.准备三台虚拟机，并且安装好mysql8.0.2x的数据库，执行以下语句：

SET SQL_LOG_BIN=0;
alter user user() identified by 'root';
create user 'root'@'%' identified by 'root';
grant all privileges on *.* to 'root'@'%';
flush privileges;
SET SQL_LOG_BIN=1;
并且一定要关闭防火墙和selinux

2.在/etc/hosts中，添加三台机器的ip和主机名：

192.168.100.80	mysql80
192.168.100.81	mysql80b
192.168.100.82	mysql80c

3.所有节点做互信（这个脚本用实验给的）
上传sshUserSetup.sh文件到指定位置
然后执行

sh sshUserSetup.sh -user root -hosts 'mysql80 mysql80b mysql80c' 
-advanced -noPromptPassphrase


测试互信-在所有的节点上都执行
ssh mysql80 date
ssh	mysql80b date
ssh mysql80c date

4.修改my.cnf文件，将下面内容添加到my.cnf中（每个节点都做）

vi /etc/my.cnf
#GTID#
gtid_mode=ON
enforce_gtid_consistency=ON
server-id=1
transaction_isolation = READ-COMMITTED
log-slave-updates=1
binlog_checksum=NONE
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay-log=/data/log-bin/relay.index
relay-log-index=/data/log-bin/relay.index
plugin_load="group_replication=group_replication.so"
slave-net-timeout=60
log_slave_updates = ON

#GROUP REPLICATION#
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name='b92c59d7-623c-11eb-b9ea-08002786ab56'
loose-group_replication_start_on_boot=OFF
loose-group_replication_local_adress="192.168.100.80:33006"
loose-group_replication_group_seeds
="192.168.100.80:33006,192.168.100.81:33006,192.168.100.81:33006"
loose-group_replication_bootstrap_group=OFF
loose-group_replication_single_primary_mode=ON
loose-group_replication_enforce_update_everywhere_checks = OFF
loose-group_replication_ip_whitelist="127.0.0.1/8,192.168.100.0/24"

其他节点配置的话，修改server-id,loose-group_replication_local_adress的值。

参数解析：
gtid_mode=ON：开启GTID，GTID（global transaction ID）是全局事务ID，当主库上提交事务或者被从库应用时，可以定位和追踪每一个事务。

enforce_gtid_consistency=ON ：强制GTID的一致性

binlog_format=row:binlog格式，MGR要求必须时ROW，不过就算不是mgr，也最好用row。

server-id=1:必须时唯一的，每个节点一个编号，不能重复。

transaction_isolation=READ_COMMITTED:MGR使用乐观锁，所以官网要求建议隔离级别时提交读，减少锁粒度。

log-slave-updates=1:因为集群会在故障恢复时相互检查binlog的数据，所以需要记录下集群内其他服务器发过来已经执行过的binlog，按GTID来区分是否执行过。

binlog_checksum=NONE:binlog校验规则，5.6之后的高版本是CRC32，低版本都是NONE，但是MGR要求使用NONE

master_info_repository=TABLE:基于安全的考虑，MGR集群要求复制模式要改成slave记录记录到表中，不然报错。

replay_log_info_repository=TABLE:同上

slave-net-timeout:从节点心跳，当从节点超过该值时未收到任何信息报文的话，默认已和集群失去联系，然后重连并且追赶这段时间主库的数据。

log_slave_updated = ON:从库从主库复制的数据，是不写入从库的binlog日志的，所以从库作为其他从库的主库时需要在配置文件中添加该参数。

#组复制设置
transaction_write_set-extraction=XXSHA64:记录事务的算法，官网建议设置该参数使用XXSHA64算法

loose-group_replication_group_name=‘b92c59d7-623c-11eb-b9ea-08002786ab56’：相当于此group的名字，是绝对唯一值，可拿select uuid()生成。主要用来区分整个内网里边的各个不同的GROUP，而且也是这个group内的GTID值的UUID。

loose-group_replication_ip_whitelist=“127.0.0.1/8,192.168.100.0/24”：IP地址白名单，默认只添加127.0.0.1，不会允许来自外部主机的连接，按需安全设置，选填参数，不是必填参数。

loose-group_replication_start_on_boot=OFF：是否随服务器启动而自动启动组复制，不建议直接启动，怕故障恢复时有扰乱数据准确性的特殊。

loose-group_replication_local_adress=“192.168.100.80:33006”：本地MGR的IP地址和端口，host:port，是MGR的端口，不是数据库的端口。

loose-group_replication_group_seeds
=“192.168.100.80:33006,192.168.100.81:33006,192.168.100.81:33006”：
需要接受本MGR实例控制的服务器IP地址和端口，是MGR的端口，不是数据库的端口。
loose-group_replication_bootstrap_group=OFF：开启引导模式，添加组成员，用于第一次搭建MGR或重建MGR的时候使用，只需要在集群内的其中一台开启。

loose-group_replication_single_primary_mode=ON：是否启动单主机模式，如果启动，则本实例是主库，提供读写，其他实例仅提供读，如果为off就是多主模式。

loose-group_replication_enforce_update_everywhere_checks = OFF：多主模式下，强制检查每一个实例是否允许该操作，如果不是多主，可以关闭。

创建用户：现在开始配置一（单）主多从的集群(每一个节点都要执行)

SET SQL_LOG_BIN=0;
CREATE USER  'repl'@'%' IDENTIFIED BY 'repl';
ALTER USER 'repl'@'%' IDENTIFIED WITH sha256_password BY 'repl';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
GRANT BACKUP_ADMIN ON *.* TO 'repl'@'%';

CREATE USER  'repl'@'localhost' IDENTIFIED BY 'repl';
ALTER USER 'repl'@'localhost' IDENTIFIED WITH sha256_password BY 'repl';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'localhost';
GRANT BACKUP_ADMIN ON *.* TO 'repl'@'localhost';

CREATE USER  'repl'@'127.0.0.1' IDENTIFIED BY 'repl';
ALTER USER 'repl'@'127.0.0.1' IDENTIFIED WITH sha256_password BY 'repl';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'127.0.0.1';
GRANT BACKUP_ADMIN ON *.* TO 'repl'@'127.0.0.1';

flush privileges;
SET SQL_LOG_BIN=1;

安装插件(每个节点都要执行)

install PLUGIN group_replication SONAME "group_replication";
--如果已经存在会报错
--查看插件
show plugins;
如果有这个就代表已经存在
group_replication		ACTIVE		GROUP REPLICATION	group_replication.so	GPL

CHANGE MASTER TO MASTER_USER='repl',MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';

在master上执行

SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;
--查看主节点的状态
select * from performance.replication_group_member;

在从节点执行

START GROUP_REPLICATION;

--查看节点状态
select * from performance.replication_group_member;

主库切换实验

1.在mysql客户端，使用shutdown;命令关闭主库；
2.然后在其他节点上执行
select * from performance.group_replication_members;
查看主库是否完成切换
3.使用sevice mysqld start; 启动刚才关闭的主库
4.启动成功后进入mysql执行：
CHANGE MASTER TO MASTER_USER='repl',MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';
start group_replication;
以启动从库的方式去启动它，然后使用
select * from performance.group_replication_members;
查看主备状态

单主切换到多主模式

#停止组复制（所有节点都执行）
stop group_replication;
set global group_replication_single_primary=OFF;
set global group_replication_enforce_update_everywhere_checks=ON;

#随便选个节点执行
SET GLOBAL group_replication_bootstap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

#其他节点执行
START GROUP_REPLICATION;

#查看组信息，所有节点都是PRIMARY
select * from performance.replication_group_members;

多主切换回单主模式：

#所有节点都执行
stop group_replication;
set global group_replication_enforce_update_everywhere_checks=OFF;
set global group_replication_sigle_primary=ON;

#主节点（你随便找一个）执行
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

#从节点执行
START GROUP_REPLICATION;

#查看主备信息
select * from performance_schema.replication_group_members;