redis 6.0启用acl后，默认default用户禁用且无+replconf/+psync/+ping等主从必需权限，导致从节点认证失败；必须显式创建专用账号并授予对应命令权限，否则复制卡在connected_state或断连。
主从复制必须显式配置独立的同步账号，否则从节点无法完成身份认证，复制会卡在 CONNECTED_STATE 或直接断连。
为什么默认的 default 用户不能用于主从同步
Redis 6.0 启用 ACL 后，default 用户默认是 off 状态（即禁用），且即使设为 on，它也不自动拥有 +replconf、+psync、+ping 等主从握手必需的命令权限。从节点在发起 PSYNC 时会被拒绝，日志里常见：
ACL denied the user 'default' from executing command 'replconf'
这不是密码错误，而是权限缺失——哪怕密码对了，也会被 ACL 拦在门外。
-
default用户不参与 ACL 权限继承，它的行为完全由requirepass和acl-pubsub-default等全局配置决定，不可靠 - 主从连接是后台长连接，不走客户端
AUTH流程，而是依赖masteruser/masterauth配置项主动认证 - 从节点不会“尝试切换用户”，它只认配置里写的那个用户名和密码，且该用户必须提前存在、启用、带权限
如何为主从同步创建专用账号
推荐使用外部 aclfile 方式管理，避免重启风险。步骤如下：
- 在
redis.conf中启用 ACL 文件：aclfile "/etc/redis/users.acl"，并确保 Redis 进程有读写权限 - 用
redis-cli创建同步账号（例如叫replica）：ACL SETUSER replica on >sync2026 ~* +replconf +psync +ping +info +client|setname - 立即保存到文件：
ACL SAVE（注意不是CONFIG REWRITE，后者不写 ACL 文件） - 在从节点配置中设置：
config set masteruser replica和config set masterauth sync2026 - 验证是否生效：
INFO replication查看master_host、master_port是否正常，master_link_status:up
关键点：+replconf 是必须的，它允许从节点向主节点上报偏移量、缓冲区大小等；+psync 是全量/增量同步的核心命令；+ping 用于心跳保活。
masteruser 账号权限容易漏掉的三个命令
很多配置失败，是因为只加了 +replconf 和 +psync，却漏掉了以下任一命令：
-
+ping：主节点定期向从节点发PING，若从节点无此权限，会拒绝响应，导致主节点判定链路异常，反复重连 -
+client|setname：从节点在建立连接后会调用CLIENT SETNAME标记自己，缺这个权限会导致连接名为空，排查困难 -
+info：部分版本的从节点在初始化阶段会执行INFO replication获取主节点状态，没权限就卡住
建议统一加上 +@admin（不含危险命令如 FLUSHALL），比零散授权更稳妥；但不要用 +@all，避免暴露管理面。
主从 ACL 配置生效后仍复制失败的排查路径
如果已配好账号但复制仍中断，按顺序检查：
- 主节点执行
ACL LOG，看是否有replconf或psync被拒记录 - 从节点执行
INFO replication，确认master_link_status是up，且master_last_io_seconds_ago小于 10 - 主节点执行
CLIENT LIST，过滤name=字段，确认从节点连接确实用了你配置的masteruser名字 - 检查主节点
aclfile文件权限是否被 SELinux 或 systemd 限制（常见于 CentOS/RHEL 系统）
最隐蔽的问题是：ACL 文件被修改后未执行 ACL LOAD，或 ACL SAVE 写入失败（磁盘满、权限不足），此时 ACL LIST 显示的是内存态，而主从连接读取的是文件态。
