redis从节点报readonly错误是默认只读行为，真正同步失败的根源常是master_link_status:down，主因包括masterauth未配置或与requirepass不一致、acl权限缺失（+replconf/+psync）、replicaof与masterauth顺序错误、dns/服务发现失效等。
从节点启动后一直报 (error) READONLY You can't write against a read only replica.
这不是同步失败的直接原因，而是正常行为——Redis 从节点默认开启 replica-read-only yes（旧版叫 slave-read-only），禁止写入是设计使然。但如果你发现从节点连 INFO replication 都显示 master_link_status:down，那问题不在只读，而在根本没连上主节点。
常见诱因是：主节点启用了密码，但从节点没配 masterauth，导致握手被拒。此时日志里通常看不到明显报错，只有反复重连、Connection refused 或静默失败。
-
masterauth必须和主节点的requirepass完全一致（包括空格、大小写） - 如果主节点用的是 ACL（Redis 6+），需确认该密码对应用户有
+replconf和+psync权限 - 配置位置必须在
replicaof之后生效（某些老版本要求顺序严格）
检查 replicaof 和 masterauth 的加载顺序与作用域
在 Redis 7+ 中，replicaof 是动态命令，但配置文件里的写法仍受解析顺序影响。若你在 redis.conf 里把 masterauth 写在 replicaof 前面，部分版本会忽略它——因为 Redis 在解析到 replicaof 时才真正初始化复制客户端，此前的 masterauth 尚未绑定到该连接上下文。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐写法：先写
replicaof host port，再紧跟着写masterauth your_password - 容器化部署（如 Docker Compose）中，避免用
command覆盖整个启动命令来传--replicaof，它不支持后续追加--masterauth；改用挂载完整redis.conf - 用
CONFIG GET masterauth在从节点运行时确认值是否已加载，而非只看配置文件
为什么 master_link_status:down 却没有连接拒绝日志？
这往往意味着从节点压根没发起有效连接——不是网络不通，而是配置未触发复制流程。典型表现：INFO replication 中 role:slave 正确，但 master_host 为空或为 nohost，master_port:-1。
- 检查
replicaof是否拼写错误（比如写成replica-of或slaveof——后者在 Redis 5.0+ 已废弃且不生效） - Kubernetes 场景下，
replicaof redis-master:6379中的redis-master必须是同一 namespace 下的 Service 名，且该 Service 的clusterIP不为None（即不能是 Headless Service 且无 endpoints） - Docker Compose 中，确保依赖顺序：从节点的
depends_on只控制启动顺序，不保证主节点服务已就绪；建议加健康检查或启动脚本重试
容易被忽略的权限与上下文隔离点
最隐蔽的问题之一：从节点配置了 masterauth，也连上了主节点，但同步卡在 SYNC 阶段，日志出现 Failed to AUTH with master。这不是密码错，而是主节点的 ACL 用户没被正确关联到复制连接。
- Redis 6+ 使用 ACL 时，
masterauth实际用于登录的用户是default（除非显式指定user参数），所以即使你设了requirepass，也要确保default用户有+replconf +psync +ping权限 - 用
ACL LIST查看当前 ACL 规则，重点确认default行是否包含这些命令权限 - 若使用非 default 用户（如
user myrepl on >mypass ~* +replconf +psync），则必须在从节点配置中写masteruser myrepl+masterauth mypass，缺一不可
