需创建带通配符主机名的管理账号clusteradmin@'%'并授权，禁用root@localhost远程修改；在my.cnf中配置plugin_load_add=group_replication.so并设loose-group_replication_local_address为本机真实IP:33061，关闭DNS解析，放行33061端口。
dba.configureInstance() 报错 “User 'root' can only connect from 'localhost'” 怎么办
这是最常见的拦路虎——dba.configureInstance() 一执行就失败，根本进不了后续步骤。原因很直接：MGR 要求集群内节点能互相通过 IP 连接，而默认的 root@localhost 账号不支持远程连接，AdminAPI 检测到后直接拒绝配置。
必须创建一个带通配符主机名、有足够权限的管理账号。不要试图改 root 的 host，MySQL 8.0+ 对 root@localhost 有特殊保护，强行修改容易导致本地登录异常。
- 在每个节点上执行：
CREATE USER 'clusteradmin'@'%' IDENTIFIED BY 'StrongPass123!'; - 授予权限：
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'clusteradmin'@'%'; - 刷新权限：
FLUSH PRIVILEGES; - 后续所有
mysqlsh连接都用这个账号，例如：mysqlsh clusteradmin@192.168.184.151:3306
创建集群时 dba.createCluster() 报 “Group Replication plugin is not installed”
这说明 MySQL Server 没加载 group_replication 插件。注意：INSTALL PLUGIN 是 SQL 命令，不能在 MySQL Shell 的 JavaScript 模式（默认模式）下直接运行；且 AdminAPI 不会自动帮你装插件，它只检查是否已启用。
必须手动在每个 MySQL 实例里执行 SQL 命令安装并持久化（否则重启失效）：
- 先切到 SQL 模式：
\sql - 执行：
INSTALL PLUGIN group_replication SONAME 'group_replication.so'; - 验证是否成功：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'group_replication';—— 输出ACTIVE才算到位 - 为防重启丢失，建议在
my.cnf中显式加载：plugin_load_add = group_replication.so
添加第二个节点时报 START GROUP_REPLICATION 失败，日志显示 “Unable to connect to group replication local address”
这不是网络不通，而是 MGR 内部通信地址（loose-group_replication_local_address）没设对。这个地址是 MGR 专用端口（如 33061），不是 MySQL 服务端口（3306），且必须能被其他节点的 IP 直接访问（不能是 127.0.0.1 或 localhost）。
检查并修正每个节点的配置（在 my.cnf 中）：
-
loose-group_replication_local_address = "192.168.184.151:33061"（对应本机真实 IP） -
loose-group_replication_group_seeds = "192.168.184.151:33061,192.168.184.152:33061,192.168.184.153:33061"（所有节点地址，顺序无关） -
report_host = 192.168.184.151（必须是 IP，禁用 DNS 解析：skip_name_resolve=ON） - 确认防火墙放行
33061端口：firewall-cmd --add-port=33061/tcp --permanent && firewall-cmd --reload
集群创建后 cluster.status() 显示某个节点状态为 UNREACHABLE 或 OFFLINE
此时别急着删节点重来。先看 cluster.describe() 输出里的 recoveryStatus 字段，多数情况是“正在追数据”，尤其当该节点启动晚或 binlog 差距大时，恢复可能耗时数分钟——AdminAPI 默认超时太短，容易误判。
更稳妥的做法是人工确认底层状态：
- 连上那个异常节点，执行：
SELECT * FROM performance_schema.replication_group_members;—— 看MEMBER_STATE是RECOVERING还是ERROR - 如果卡在
RECOVERING，查错误日志：tail -n 50 /var/log/mysqld.log | grep -i "group_replication\|error" - 常见根因：磁盘满、relay log 路径不可写、
binlog_transaction_dependency_tracking和transaction_write_set_extraction参数在各节点不一致（必须全相同） - 切记：
cluster.rejoinInstance()只适用于短暂断连；若节点已彻底掉出组，要用cluster.addInstance()重新加入，而不是rejoin
真正麻烦的是跨机房或高延迟网络下 group_replication_flow_control_mode=QUOTA 导致的假性离线——这种场景必须调大 group_replication_member_expel_timeout，否则节点会被误驱逐。
