Redis从节点执行写命令必然报READONLY错误,因其默认启用slave-read-only yes硬性限制;该错误与网络、密码无关,是内置安全机制,关闭只读会导致主从数据分裂。

会报错,但不是必然——取决于你连的是谁、发的是什么命令、以及从节点是否处于可读状态。
从节点执行写命令时固定报 READONLY 错误
Redis 从节点默认开启只读模式(slave-read-only yes),这是硬性限制。一旦你连接到从节点并尝试执行 SET、DEL、INCR 等任何写操作,立刻返回:
(error) READONLY You can't write against a read only replica
- 这个错误和网络、密码、配置无关,是 Redis 内置行为
- 即使你在配置文件里删掉
slave-read-only或设为no,重启后仍可能因安全策略被强制重置为yes - 不建议关闭只读:写入从节点会导致主从数据分裂,后续同步会丢数据或触发全量重同步
连接了从节点却误发写请求的典型场景
最常见于客户端未区分角色,或连接池配置错误:
- Spring Boot 中
spring.redis.host和spring.redis.slave.host配置反了,导致写逻辑实际打到了从节点 - 使用 Jedis 或 Lettuce 时手动指定 IP 端口,但没校验
INFO replication的role字段就直接复用连接 - 哨兵或集群模式下,客户端未正确解析
SENTINEL get-master-addr-by-name返回结果,连上了旧的 master(已被降级为 slave)
排查方法很简单:连上目标节点执行 INFO replication,看返回的 role:slave 和 slave_read_only:1 是否同时存在。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Redis Cluster 模式下从节点读取报 MOVED 错误
这不是主从复制的问题,而是 Cluster 协议的默认行为:从节点默认拒绝所有读请求,并强制重定向到对应 slot 的主节点:
(error) MOVED 742 192.168.1.100:6379
- 必须在连接后先执行
READONLY命令,才能让该连接允许从节点读取(哪怕数据可能过时) -
READONLY是连接级指令,断开重连即失效,不能靠配置文件持久化 - 如果业务能接受最终一致性,且明确知道从节点延迟可控,才考虑启用;否则应始终读主
从节点本身不可达或同步中断时的读取表现
这时不会报具体 Redis 错误,但会出现超时或空响应:
- 主从断连后,从节点仍可正常响应
GET,只是返回的是断连前最后同步的数据 - 若从节点因磁盘满、OOM 被 kill,再次启动后尚未完成 RDB 加载,
GET可能返回(nil)或直接连接拒绝 - 监控关键指标:用
INFO replication查master_link_status:up、slave_repl_offset与主节点master_repl_offset的差值
真正容易被忽略的是:从节点“能连上”不等于“数据最新”,它可能已落后几秒甚至几分钟,而这种延迟在日志和错误码里完全不体现。

















