group replication复制账号必须仅授予replication slave权限、绑定具体ip（禁用'%'）、启用ssl并校验证书身份，且需定期轮换密码；其他权限如select、super、replication client均非必需且增加安全风险。
Group Replication 的复制账号必须用 REPLICATION SLAVE 权限
别给 SELECT、SUPER 或 ALL PRIVILEGES——这些权限跟复制完全无关，只会扩大攻击面。MySQL 8.0+ 中，REPLICATION SLAVE 是唯一必需且足够用的权限，它只允许读取 binlog 流和执行 SHOW BINLOG EVENTS，不涉及任何表数据访问。
常见错误是顺手加 REPLICATION CLIENT，以为“监控需要”，但该权限仅用于 SHOW MASTER STATUS 等管理命令，START GROUP_REPLICATION 启动时根本不需要它。验证方式很简单：SHOW GRANTS FOR 'rpl_user'@'192.168.10.22'; 输出应只含一行：GRANT REPLICATION SLAVE ON *.* TO `rpl_user`@`192.168.10.22`。
账号必须绑定具体 IP，禁止用 '%' 通配符
写成 'rpl_user'@'192.168.10.22'（从库真实内网 IP）或最小网段如 'rpl_user'@'10.0.5.0/24'，而不是 'rpl_user'@'%'。binlog 里可能包含脱敏前手机号、密码哈希等敏感字段，@'%' 意味着任意 IP 都能连主库拉取全量变更日志。
若从库经跳板机或 NAT 出口连接，实际源 IP 可能不是配置里的地址，需在主库抓包确认：tcpdump -i any port 3306 -A 查看 TCP 连接来源；DNS 解析不稳定时主机名会失败，优先用 IP。
密码不能明文写进 CHANGE MASTER TO
MySQL 8.0.27+ 支持密钥交换机制传递密码，避免硬编码泄露：
- 主库创建账号时启用公钥交换：
ALTER USER 'rpl_user'@'192.168.10.22' REQUIRE SSL; - 从库执行：
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='', GET_SOURCE_PUBLIC_KEY=1, SOURCE_SSL=1; - 密码由 MySQL 内部 RSA 密钥对加密传输，不走网络明文
旧版本若必须传明文密码，至少确保 CHANGE REPLICATION SOURCE TO 语句不存于脚本或日志中，执行后立即清空历史记录：history -c。
SSL 必须启用且校验证书身份
仅设 source_ssl=1 不够，还需校验服务端证书是否匹配目标主机名，否则中间人攻击仍可解密：
- 主库与从库均配置有效 TLS 证书（CA 签发，非自签名）
- 从库连接时强制校验：
CHANGE REPLICATION SOURCE TO SOURCE_SSL=1, SOURCE_SSL_VERIFY_SERVER_CERT=1; - 对应系统变量：
group_replication_ssl_mode=VERIFY_IDENTITY（所有节点必须一致）
注意：如果用了 MySQL 通信栈（group_replication_communication_stack=MYSQL），组内通信和分布式恢复共用同一套 SSL 配置，漏配一项就等于整条链路裸奔。
最易被忽略的是账号生命周期管理——复制账号长期有效，但没人定期轮换或审计。建议每 90 天执行一次 ALTER USER 改密，并同步更新所有节点的 CHANGE REPLICATION SOURCE TO 配置，闲置账号直接 DROP USER 删除，而非仅撤权限。
