必须统一主机名和/etc/hosts，否则mgr因无法解析节点地址而卡在recovering状态；三节点需不同主机名、hosts严格一致、禁用selinux与防火墙、正确配置4个关键参数、手动安装插件并创建兼容认证的复制用户。
必须先统一主机名和 /etc/hosts，否则所有后续操作都会卡在 RECOVERING 状态。
为什么 /etc/hosts 配置失败会导致 MGR 启动失败
MySQL Group Replication 依赖节点间通过主机名互相解析通信，group_replication_local_address 和 group_replication_group_seeds 中的地址最终会被 DNS 或 hosts 解析。如果解析失败（比如返回 Unknown MySQL server host 'mgr-node2'），MGR 插件根本无法建立连接，状态永远停留在 RECOVERING 或直接报错退出。
- 三台节点必须使用**完全不同的主机名**（如
mgr-node1、mgr-node2、mgr-node3），且不能是localhost或127.0.0.1 -
/etc/hosts必须在**每台节点上单独编辑**，内容严格一致，IP 与主机名一一对应，不加端口、不加空格、不写注释 - 不要依赖 DNS；即使你有内网 DNS，也必须在
/etc/hosts中显式声明，这是 MGR 官方明确要求的硬性前提
SELinux 和防火墙必须关或精准放行
SELinux 会拦截 MGR 插件对网络端口（尤其是 33061）的 bind 操作，而默认 firewalld 会直接丢弃该端口的所有包——这两者任一启用，MGR 节点之间就无法完成握手。
- 临时关闭 SELinux：
setenforce 0；永久关闭：修改/etc/selinux/config中SELINUX=disabled并重启 - 防火墙必须开放两个端口：
3306（SQL 连接）和33061（MGR 内部通信），仅开放3306不够 - 生产环境不建议直接
systemctl stop firewalld，应执行：firewall-cmd --permanent --add-port=3306/tcp和firewall-cmd --permanent --add-port=33061/tcp，再firewall-cmd --reload
my.cnf 中最关键的 4 个 MGR 参数不能写错
MGR 启动失败的绝大多数配置类问题，都集中在以下四个参数的值是否合法、是否跨节点一致、是否与其他参数冲突。
-
loose-group_replication_group_name：必须是合法 UUID 格式（如c482bdca-d23e-11eb-972a-fa163edf10ea），且**所有节点完全相同**；不能用 IP、主机名或随机字符串代替 -
loose-group_replication_local_address：格式为host:port，host 必须能被本机ping通且在/etc/hosts中存在；port 推荐固定为33061，避免与业务端口混淆 -
loose-group_replication_group_seeds：列出所有节点的local_address，用英文逗号分隔；顺序无关，但**必须包含自身地址**（否则首次启动可能失败） -
loose-group_replication_bootstrap_group：**仅在第一个节点首次启动时设为ON，其余节点必须为OFF；且首次启动后立即设回OFF，否则下次重启会触发二次引导导致脑裂**
插件加载和复制用户必须在配置生效后手动执行
MySQL 8.0 的 MGR 是插件机制，my.cnf 中的 plugin_load_add 或 loose-plugin-load 只负责加载，不自动启用；复制用户权限也必须显式赋予，且认证方式要匹配。
- 插件安装命令必须在每个节点的 MySQL 客户端中执行：
INSTALL PLUGIN group_replication SONAME 'group_replication.so'; - 复制用户需用
caching_sha2_password（MySQL 8.0 默认）创建，不能用mysql_native_password，否则CHANGE REPLICATION SOURCE会报Access denied - 用户权限至少包括：
REPLICATION SLAVE和BACKUP_ADMIN；GRANT后必须FLUSH PRIVILEGES - 恢复通道必须显式指定：
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='xxx' FOR CHANNEL 'group_replication_recovery';
最容易被忽略的是：MGR 启动后，SELECT * FROM performance_schema.replication_group_members; 返回的 MEMBER_STATE 为 ONLINE 才算真正成功；只要有一个是 RECOVERING 或 ERROR，说明 hosts、端口、UUID、用户权限中至少有一处没对齐——这时候别急着查日志，先比对这四点。
