节点信息
- mgr1：192.168.24.140
- mgr2：192.168.24.141
- mgr3：192.168.24.142
- MGR 通信端口：33061
官网：
提前下载好mysql
# 1. 安装 YUM 仓库
[root@mgr1 ~]# dnf install https://dev.mysql.com/get/mysql84-community-release-el10-2.noarch.rpm
# 2. 安装数据库
[root@mgr1 ~]# dnf install mysql-community-server -y
# 3. 启动数据库
[root@mgr1 ~]# systemctl start mysqld一、所有节点必须统一做的配置（3 台都执行）
1. 配置主机名（每台自己改）
# mgr1 执行
hostnamectl set-hostname mgr1 && bash
# mgr2 执行
hostnamectl set-hostname mgr2 && bash
# mgr3 执行
hostnamectl set-hostname mgr3 && bash2. 配置 hosts（3 台都加一样的）
cat >> /etc/hosts <<EOF
192.168.24.140 mgr1
192.168.24.141 mgr2
192.168.24.142 mgr3
EOF3. 防火墙放行
# MySQL 服务端口
firewall-cmd --add-port=3306/tcp --permanent
# MGR 组通信端口（必须！）
firewall-cmd --add-port=33061/tcp --permanent
firewall-cmd --reload
firewall-cmd --list-all4. SELinux 放行
不过如果还没有启动过mysqld，这里会缺少目录/var/lib/mysql
# 让 MySQL 可以网络连接
setsebool -P mysql_connect_any 1
setsebool = 设置 SELinux 开关
-P = 永久生效（重启不掉）
mysql_connect_any = SELinux 里专门给 MySQL 开放网络的开关
1 = 开启（0=关闭）
因为本身selinux它不信任任何程序，它不让程序随便访问网络、随便读写文件
# 让 MySQL 可以读写数据目录
semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"
restorecon -R /var/lib/mysql
semanage fcontext
= 设置 SELinux 的目录安全标签
-a
= 添加（add）
-t mysqld_db_t
= 给目录打上 MySQL 数据目录专用标签
"/var/lib/mysql(/.*)?"
= 这个目录 以及里面所有文件、子目录二、每台机器的 my.cnf 配置
mgr1（192.168.24.140）配置
集群uuid可以自己生成一个
两种方法
[root@mgr2 ~]# uuidgen
c7d3de28-d28f-437c-90ef-ee318e0da6bf
或者登入mysql后
SELECT UUID();
+--------------------------------------+
| UUID() |
+--------------------------------------+
| 8f9e7d6c-1122-3344-5566-778899aabbcc |
+--------------------------------------+
格式正确就行
8-4-4-4-12my.cnf配置
这个是我最开始写的配置文件，比官方文档多加了东西，会导致其他除第一节点加入mgr集群失败
就是多了以下四行，当成功加入后再写入就没事了，因为mgr集群自己会启动
log_bin=ON
binlog_format=ROW
log_slave_updates=ON
不需要自己去写在配置文件中，本来log_bin默认关闭，但是这样写强行打开，第一次强制修改密码时就产生了事务，这样节点就脏了，无法加入mgr，后面有解决方法。
# 二进制日志开启
log_bin=ON
binlog_format=ROW
log_replica_updates=ON
binlog_checksum=NONE
1. log_bin=ON
开启二进制日志（binlog）
→ MySQL 一启动，就开始记录所有操作
→ 建用户、改密码、授权、执行命令 全都会被记录成事务
→ 你还没加入集群，本地就已经有事务了
→ MGR 直接拒绝加入！
2. binlog_format=ROW
binlog 记录格式，就是不记录修改语句本身，记录修改前后数据
→ 记录每一行数据的变化
→ 本身无害，但只要 log_bin 开启，就会产生事务
3.log_replica_updates=ON
让从库也记录日志，同步主库后自己也记录日志，在级联复制主库 A → 从库 B → 从库 C
→ 新版叫 log_replica_updates=ON
→ 只要开启，节点自己也会产生 GTID 事务
→ 还没进集群，本地就脏了
4. binlog_checksum=NONE
关闭 binlog 校验
→ 老版本需要，MySQL 8.0+ 完全不需要
→ 加了没用，还容易出问题
加这 4 行 = 节点刚启动就产生本地事务
**MGR 安全规则：
只要本地有事务，就绝对不允许加入空集群！**
所以一直报：
This member has more executed transactions than those present in the group按照官方添加的模版
[root@mgr3 ~]# cat /etc/my.cnf
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/8.4/en/server-configuration-defaults.html
[client]
user=root
password=MySQL@123
[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#
# Remove the leading "# " to disable binary logging
# Binary logging captures changes between backups and is enabled by
# default. It's default setting is log_bin=binlog
# disable_log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=142
gtid_mode=ON
enforce_gtid_consistency=ON
plugin_load_add=group_replication.so
group_replication_group_name="5dbabbe6-8050-49a0-9131-1de449167446"
group_replication_start_on_boot=OFF
group_replication_local_address="192.168.24.142:33061"
group_replication_group_seeds="192.168.24.140:33061,192.168.24.141:33061,192.168.24.142:33061"
group_replication_bootstrap_group=offmgr2（192.168.24.141）配置
只改 2 行，其他完全一样
server_id=141
group_replication_local_address="192.168.24.141:33061"mgr3（192.168.24.142）配置
只改 2 行，其他完全一样
server_id=142
group_replication_local_address="192.168.24.142:33061"三、3 台都启动 MySQL
systemctl start mysqld
systemctl enable mysqld四、3 台都配置复制用户（必须全部执行）
1. 获取初始密码
grep 'temporary password' /var/log/mysqld.log2. 登录并改 root 密码
ALTER USER root@localhost IDENTIFIED BY 'MySQL@123';
FLUSH PRIVILEGES;3. 创建 MGR 专用用户（3 台都执行）
SET SQL_LOG_BIN=0;
CREATE USER 'repl'@'%' IDENTIFIED BY 'Repl@123';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
GRANT CONNECTION_ADMIN ON *.* TO 'repl'@'%';
GRANT BACKUP_ADMIN ON *.* TO 'repl'@'%';
GRANT GROUP_REPLICATION_STREAM ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
1.
SET SQL_LOG_BIN=0;
意思：
关闭当前会话的 binlog 记录！
为什么要关？
如果不关闭，你创建账号的命令会被同步到其他节点
其他节点还没配置，就会收到重复创建用户的命令
直接报错：user exists
总结：
关闭 binlog → 让这条账号命令只在本地执行，不同步！
2.
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
意思：
授予复制权限（REPLICATION SLAVE这是一个权限）
让这个账号可以做主从同步
3.
GRANT CONNECTION_ADMIN ON *.* TO 'repl'@'%';
意思：
授予连接管理权限
MGR 节点之间需要频繁建立连接
4.
GRANT BACKUP_ADMIN ON *.* TO 'repl'@'%';
意思：
允许备份权限
MGR 恢复数据时需要
5.
GRANT GROUP_REPLICATION_STREAM ON *.* TO 'repl'@'%';
意思：
MGR 专用流权限
没有这条，节点无法加入集群，直接报 3092 错误
6.
FLUSH PRIVILEGES;
意思：
刷新权限，让刚才的授权立刻生效！4. 配置 MGR 恢复通道（3 台都执行）
CHANGE REPLICATION SOURCE TO
SOURCE_USER='repl',
SOURCE_PASSWORD='Repl@123'
FOR CHANNEL 'group_replication_recovery';
1. CHANGE REPLICATION SOURCE TO
意思：配置复制源信息
MySQL 8.0 新语法
老版本叫 CHANGE MASTER TO
2. SOURCE_USER='repl'
MGR 节点之间互相连接用的用户名
就是刚才创建的那个同步账号
3. SOURCE_PASSWORD='Repl@123'
节点同步时用的密码
4. FOR CHANNEL 'group_replication_recovery'
指定这条配置只给 MGR 恢复通道使用
这个通道名是固定死的！
不能改！不能改！不能改！
必须写：
group_replication_recovery
作用：
当新节点加入集群、节点重启、节点故障恢复
MGR 自动用这个通道 + 这个账号去同步数据
三、最关键总结
这条命令 = 给 MGR 配置 "节点间同步账号"
没有它 = 节点无法加入集群
没有它 = 直接报 3092 错误这之后检查配置文件中写的插件group_replication.so有没有，没有要进行下载
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
mysql> SHOW PLUGINS;
+----------------------------------+----------+--------------------+----------------------+---------+
| Name | Status | Type | Library | License |
+----------------------------------+----------+--------------------+----------------------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
| sha256_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| caching_sha2_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| sha2_cache_cleaner | ACTIVE | AUDIT | NULL | GPL |
| daemon_keyring_proxy_plugin | ACTIVE | DAEMON | NULL | GPL |
| CSV | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL |
| InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL |
| INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMPMEM | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMPMEM_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP_PER_INDEX | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP_PER_INDEX_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_BUFFER_PAGE | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_BUFFER_PAGE_LRU | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_BUFFER_POOL_STATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TEMP_TABLE_INFO | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_METRICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_DEFAULT_STOPWORD | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_BEING_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_CONFIG | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_INDEX_CACHE | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_INDEX_TABLE | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLESTATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_INDEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLESPACES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_COLUMNS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_VIRTUAL | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CACHED_INDEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_SESSION_TEMP_TABLESPACES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MRG_MYISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL |
| TempTable | ACTIVE | STORAGE ENGINE | NULL | GPL |
| ARCHIVE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| BLACKHOLE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| FEDERATED | DISABLED | STORAGE ENGINE | NULL | GPL |
| ndbcluster | DISABLED | STORAGE ENGINE | NULL | GPL |
| ndbinfo | DISABLED | STORAGE ENGINE | NULL | GPL |
| ndb_transid_mysql_connection_map | DISABLED | INFORMATION SCHEMA | NULL | GPL |
| ngram | ACTIVE | FTPARSER | NULL | GPL |
| mysqlx_cache_cleaner | ACTIVE | AUDIT | NULL | GPL |
| mysqlx | ACTIVE | DAEMON | NULL | GPL |
| mysql_native_password | DISABLED | AUTHENTICATION | NULL | GPL |
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |
+----------------------------------+----------+--------------------+----------------------+---------+
49 rows in set (0.00 sec)五、启动 MGR（顺序绝对不能错）
✅ 第一步：只在 mgr1 执行（引导集群）
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
1. SET GLOBAL group_replication_bootstrap_group=ON;
开启 "创世模式"
告诉 MySQL：
我是第一个节点，我要当集群的 "创始人"
2. START GROUP_REPLICATION;
启动 MGR 集群服务
执行完这句，这个节点就变成：
整个集群的第一个在线节点
3. SET GLOBAL group_replication_bootstrap_group=OFF;
立刻关闭创世模式！
必须执行！必须执行！
不然重启后会再次创建集群 → 脑裂、集群坏掉✅ 第二步：在 mgr2、mgr3 执行
这里可能会出现报错，查看错误日志
其中有
This member has more executed transactions than those present in the group
你本地自己执行过 SQL，有独立事务 → MGR 不让你加入！
RESET BINARY LOGS AND GTIDS;
重置后就可以正常加入了
START GROUP_REPLICATION;六、查看集群状态
SELECT * FROM performance_schema.replication_group_members;
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | a3acd2e3-3c8d-11f1-8937-000c2906b162 | mgr2 | 3306 | ONLINE | SECONDARY | 8.4.8 | XCom |
| group_replication_applier | ab958bde-3c8d-11f1-a4fb-000c29ebd6a2 | mgr1 | 3306 | ONLINE | PRIMARY | 8.4.8 | XCom |
| group_replication_applier | b479cd59-3c9c-11f1-8e3b-000c29a02a54 | mgr3 | 3306 | ONLINE | SECONDARY | 8.4.8 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)这是单主模式
单主优势
无并发写冲突
多个节点不会同时改同一行数据，MGR 不用做冲突检测、回滚，性能最高、最稳定。
自动故障转移
主库挂了，集群自动选举新主，业务不用改任何配置，高可用最强。
数据一致性最稳
不会出现事务冲突、死锁、回滚、数据不一致问题。
兼容所有业务、ORM、框架、分库分表
部署简单、排错简单、官方主推
单主缺点
写压力集中在主库，从库只能读不能写。还有多主模式
多主优势
分布式写负载
写请求可以分散到多个节点，不用集中压力到一个主库。
没有单点写瓶颈
适合写并发特别高、无法扩容单主的场景。
任意节点挂一个，不影响其他节点写入
不用等待选举，剩下节点继续写。
多主致命缺点（非常重要）
多节点同时修改同一行 → 自动冲突检测 → 事务直接回滚报错
业务必须自己做分片、路由，保证不同节点写不同数据。
不能自动故障转移
性能比单主低（每个事务都要全局冲突校验）
事务隔离级别严格限制
极易数据不一致、死锁、业务报错
集群初始化后不能随便切换单主↔多主多主模式配置
group_replication_single_primary_mode=OFF
group_replication_enforce_update_everywhere_checks=ON
单主关闭，默认开启多主
开启全局一致性检查两个模式可以在线切换，但是非常不建议，运行模式完全不一样
-- 切多主
SELECT group_replication_switch_to_multi_primary_mode();
-- 切单主
SELECT group_replication_switch_to_single_primary_mode();看到 3 台都是 ONLINE 就成功了！
七、如果你不小心在 mgr2/mgr3 执行了 bootstrap
执行这 4 行重置：
STOP GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
RESET BINARY LOGS AND GTIDS;
START GROUP_REPLICATION;八、切换主节点
官网：
MySQL :: MySQL 8.4 Reference Manual :: 20.5.1.1 Changing the Primary
https://dev.mysql.com/doc/refman/8.4/en/group-replication-change-primary.html
当主节点需要进行维护时，或者执行滚动升级时，就可以对其进行切换，将主节点切换到其他节点。
在命令行模式下，可以使用 group_replication_set_as_primary() 这个 udf 实现切换，例如：
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | a3acd2e3-3c8d-11f1-8937-000c2906b162 | mgr2 | 3306 | ONLINE | SECONDARY | 8.4.8 | XCom |
| group_replication_applier | ab958bde-3c8d-11f1-a4fb-000c29ebd6a2 | mgr1 | 3306 | ONLINE | PRIMARY | 8.4.8 | XCom |
| group_replication_applier | b479cd59-3c9c-11f1-8e3b-000c29a02a54 | mgr3 | 3306 | ONLINE | SECONDARY | 8.4.8 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
mysql> SELECT group_replication_set_as_primary('b479cd59-3c9c-11f1-8e3b-000c29a02a54');
+--------------------------------------------------------------------------+
| group_replication_set_as_primary('b479cd59-3c9c-11f1-8e3b-000c29a02a54') |
+--------------------------------------------------------------------------+
| Primary server switched to: b479cd59-3c9c-11f1-8e3b-000c29a02a54 |
+--------------------------------------------------------------------------+
1 row in set (0.02 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | a3acd2e3-3c8d-11f1-8937-000c2906b162 | mgr2 | 3306 | ONLINE | SECONDARY | 8.4.8 | XCom |
| group_replication_applier | ab958bde-3c8d-11f1-a4fb-000c29ebd6a2 | mgr1 | 3306 | ONLINE | SECONDARY | 8.4.8 | XCom |
| group_replication_applier | b479cd59-3c9c-11f1-8e3b-000c29a02a54 | mgr3 | 3306 | ONLINE | PRIMARY | 8.4.8 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)九、添加新节点，删除旧节点，重新加入集群，重启集群，手动换主库，单主多主转换
一、加入节点
1. 新节点前置条件
- MySQL 初始化完成
- 配置文件 my.cnf 与集群其他节点完全一致
- server-id 不同
- group_name、group_seeds、local_address 相同
- 不手动开启 log_bin、binlog_format
- 创建 MGR 专用账号
2. 新节点执行（关键步骤）
-- 1. 配置复制通道
SET SQL_LOG_BIN=0;
CREATE USER IF NOT EXISTS 'repl'@'%' IDENTIFIED BY 'Repl@123';
GRANT REPLICATION SLAVE, REPLICATION SLAVE ADMIN, CONNECTION_ADMIN, BACKUP_ADMIN ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
-- 2. 配置MGR恢复通道
CHANGE REPLICATION SOURCE TO
SOURCE_USER='repl',
SOURCE_PASSWORD='Repl@123'
FOR CHANNEL 'group_replication_recovery';3. 全量克隆数据（推荐！避免 GTID 不一致）
当然直接start replication；也行，但是当数据很多时，同步速度慢，可以先做一个克隆。
-- 设置捐献者节点（选 SECONDARY 节点，不影响主库）
SET GLOBAL clone_valid_donor_list = '192.168.24.141:3306';
相当于我允许你从 192.168.24.141 这个地址克隆数据。
-- 关闭MGR、关闭只读
STOP GROUP_REPLICATION;
SET GLOBAL super_read_only = 0;
-- 开始克隆（端口 3306，不是 33061）
CLONE INSTANCE FROM 'repl'@'192.168.24.141':3306 IDENTIFIED BY 'Repl@123';
把远端 192.168.24.141 这台 MySQL 的全部数据，完整克隆到本地这台新 MySQL。
用上BACKUP_ADMIN这个权限
3306 = MySQL 服务端口（业务、数据、克隆 都走它）
客户端连接
数据查询
克隆数据
账号密码登录
33061 = MGR 集群内部通信端口（只用于节点心跳、选举、同步消息）
不承载数据
不登录
不能用来克隆数据克隆完成后 MySQL 自动重启
4. 启动 MGR 加入集群
START GROUP_REPLICATION;5. 查看集群状态
SELECT MEMBER_ID, MEMBER_HOST, MEMBER_STATE, MEMBER_ROLE
FROM performance_schema.replication_group_members;二、删除 MGR 节点
1. 临时退出（以后还能加回来）
STOP GROUP_REPLICATION;需要恢复时：
START GROUP_REPLICATION;2. 永久退出集群（清空所有复制信息）
STOP GROUP_REPLICATION;
RESET MASTER;
RESET SLAVE ALL;节点彻底脱离集群。
三、异常节点重新加入集群
场景
节点网络中断、MySQL 崩溃、被集群踢出状态变为：UNREACHABLE
恢复方法
START GROUP_REPLICATION;- 自动尝试恢复
- 自动追数据
- 正常后变为 ONLINE
超时踢出规则：踢出时间 =
group_replication_member_expel_timeout+ 5 秒
四、MGR 集群全部关闭后的重启
整个集群所有节点都关闭 → 重启必须按顺序！
1. 选择第一个启动的节点（引导节点）
SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;该节点自动成为 PRIMARY
2. 其他节点启动
START GROUP_REPLICATION;自动加入集群，成为 SECONDARY
五、单主模式手动切换主库（指定节点）
上面有例子
SELECT group_replication_set_as_primary('节点UUID');查看 UUID：
SELECT MEMBER_ID, MEMBER_HOST FROM performance_schema.replication_group_members;六、多主 ↔ 单主 切换
多主 → 单主（指定主库）
SELECT group_replication_switch_to_single_primary_mode('节点UUID');单主 → 多主
SELECT group_replication_switch_to_multi_primary_mode();七、核心总结
- 新节点必须干净，无本地 GTID 事务
- 新增节点优先用 clone 克隆数据
- 集群全部关闭重启必须引导第一个节点
- 删除节点：stop + reset 即可永久退出
- 异常节点直接 start group_replication 自动恢复
- 切换主库用函数，必须加 select