Group Replication强制要求为group_replication_recovery通道单独配置专用账号，需在所有节点创建同名同密用户，授予REPLICATION SLAVE和GROUP_REPLICATION_ADMIN权限，并显式执行CHANGE MASTER TO绑定凭据，否则启动失败或状态卡在RECOVERING。
group_replication_recovery通道必须用专用账号
MySQL Group Replication 不会复用主从复制的 MASTER_USER，它强制要求为恢复通道 group_replication_recovery 单独配置一个账号。这个账号只用于节点间传输事务日志（binlog events），不是给应用或DBA连的，权限和生命周期都必须严格限定。
常见错误是直接复用 root 或已有复制用户，结果 START GROUP_REPLICATION 报 ER_ACCESS_DENIED_ERROR 或卡在 RECOVERING 状态，日志里反复出现 Failed to connect to recovery source。
- 账号必须在所有节点上创建，且用户名、密码完全一致（MGR 不同步账号，靠人工对齐）
- 密码不能含特殊字符如
@、/、:，否则CHANGE MASTER TO会解析失败 - 必须先执行
SET SQL_LOG_BIN=0创建账号，避免该操作被写入 binlog 导致循环同步 - 账号 host 部分建议用
'%'或明确网段（如'192.168.157.%'），不能只写'localhost'—— MGR 恢复连接走的是 TCP，不走 socket
GRANT GROUP_REPLICATION_ADMIN 是硬性权限
仅给 REPLICATION SLAVE 权限不够。MGR 插件在启动时会尝试调用内部管理接口（比如检查组状态、广播心跳），这些操作需要 GROUP_REPLICATION_ADMIN 权限。漏掉这条，START GROUP_REPLICATION 直接拒绝，错误信息是 Access denied; you need (at least one of) the GROUP_REPLICATION_ADMIN privilege(s)。
这个权限从 MySQL 8.0.12 起才引入，低于该版本无法启用 MGR。
- 执行顺序不能错：先
CREATE USER，再GRANT REPLICATION SLAVE，最后GRANT GROUP_REPLICATION_ADMIN -
GROUP_REPLICATION_ADMIN是全局权限，不能限制到库或表级；也不支持WITH GRANT OPTION - 不要给
SUPER或SYSTEM_VARIABLES_ADMIN等额外权限——MGR 不需要，反而增加攻击面
CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' 必须显式执行
MGR 不会自动推导恢复账号。即使你已创建好用户并授了权，也必须手动运行 CHANGE MASTER TO 命令把凭据绑定到 group_replication_recovery 这个固定通道名上。漏掉这步，节点永远无法拉取其他成员的 binlog，状态卡死在 RECOVERING。
注意：该命令中的 MASTER_PORT 指的是目标节点的 MySQL 服务端口（如 3306），不是 MGR 通信端口（33061）；MASTER_HOST 必须能被本机 DNS 或 /etc/hosts 解析，不能填 127.0.0.1。
- 示例命令：
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='xxx' FOR CHANNEL 'group_replication_recovery'; - 每个节点都要执行，且
MASTER_USER和MASTER_PASSWORD必须与自己创建的账号一致（即“用自己的账号连别人”） - 执行后可用
SELECT * FROM performance_schema.replication_connection_configuration WHERE CHANNEL_NAME = 'group_replication_recovery';验证是否生效
账号密码不一致会导致集群分裂而非报错
这是最容易被忽略的坑：三个节点中只要有一个节点的 repl 用户密码和其他两个不一致，该节点仍可能加入组、显示 ONLINE，但实际无法接收事务。因为 MGR 的恢复连接是异步建立的，失败日志埋得很深（通常在 mysqld-error.log 里搜 group_replication_recovery 或 SSL handshake failed），而 performance_schema.replication_group_members 看起来一切正常。
验证方式不是看状态，而是查 performance_schema.replication_applier_status_by_coordinator 中该通道的 LAST_ERROR_NUMBER 是否为 0，以及 LAST_PROCESSED_TRANSACTION 是否持续更新。
- 上线前务必在每台节点上运行：
mysql -urepl -pxxx -h<other-node-ip> -P3306 -e "SELECT 1"</other-node-ip>，逐个测试连通性 - 密码建议用
openssl rand -base64 16生成，避免手输误差 - 生产环境禁止用
mysql_config_editor存密——它不支持多通道凭据隔离，容易混用
