复制链路的凭据配置
主库一旦启用密码或 ACL 认证，从库就必须带着相同凭据去连接，否则握手阶段就会被拒绝。凭据配置在从库一侧：masterauth 指定密码，6.0 起可以配合 masteruser 指定 ACL 用户名。认证不仅发生在初次握手，后续的数据流同步和故障恢复也复用同一套凭据，因此主库与从库的配置必须长期保持一致，任一侧变更都要同步处理。
基本信息
| 从库配置 | masterauth <password> |
|---|---|
| ACL 用户 | masteruser <username>（6.0 及以上） |
| 配置位置 | 从库的 redis.conf，或运行时 CONFIG SET |
| 生效检查 | INFO replication 的 master_link_status |
| 敏感度 | 配置文件里为明文，需要收紧文件权限 |
典型使用场景
- 主库启用 requirepass 后，逐台为从库补齐认证配置
- ACL 体系下为复制单独建用户，只授予复制链路上必要的权限
- 密码轮换：主库改密后同步更新所有从库的 masterauth，避免链路中断
- 排查 master_link_status 为 down 时，先确认两侧凭据是否一致
- 重建或迁移从库时，把凭据核对列进配置检查清单
配置与核对
配置与核对
redis-cli CONFIG SET masterauth 'app-password' # 从库侧填写主库密码
redis-cli CONFIG SET masteruser appuser # ACL 体系下指定用户名
redis-cli INFO replication | grep -E 'master_link_status|master_host|master_port'
redis-cli -h <从库> PING # 先确认从库自身可访问
redis-cli CONFIG REWRITE # 确认链路恢复后落盘
# 主库轮换密码后，所有从库的 masterauth 都要同步更新链路状态速读
| 字段 | 正常表现 | 异常含义 |
|---|---|---|
| master_link_status | up | down 表示握手或同步失败，凭据错误是常见原因 |
| master_host / master_port | 与预期主库一致 | 不一致说明从库挂到了别的主库 |
| master_last_io_seconds_ago | 数值很小 | 持续增大说明数据流已经断了 |
| master_sync_in_progress | 0 | 长期为 1 说明全量同步迟迟完不成 |
认证信息在配置文件里是明文，权限应收紧到仅 Redis 运行用户可以读取；容器化部署时不要写进镜像层，改用挂载配置文件或运行时注入的方式，减少泄露面。
ACL 复制用户的最小权限一般包含复制相关的读命令与必要的连接权限，不要图省事直接套用管理员账号：一旦从库被入侵，复制的凭据就成了横向移动的跳板。凭据轮换时，先改从库配置再改主库，可以避免链路在中间窗口完全断开。
如果从库自身也对外提供服务，它自身访问控制（requirepass 或 ACL）与 masterauth 是两件事：前者约束谁可以连这台从库，后者是这台从库连主库时出示的凭据，排查认证类报错时要先分清是哪一侧在拒绝。