Redis 写入报 READONLY：先确认节点角色和主写入端点

Redis 的读请求正常、写请求却返回 READONLY You can't write against a read only replica，先确认应用实际连到的节点角色。这个错误表示写操作落到了拒绝写入的副本；数据目录可写、磁盘空间充足，并不能改变节点角色。

它与 NOAUTH、WRONGPASS、ACL 的 NOPERM，以及持久化失败时的 MISCONF 是不同问题。下面以自建 Redis 主从或 Sentinel 部署为主；Redis Cluster 和托管服务需要使用各自的拓扑发现或主写入端点。

在发生错误的端点上查看角色

使用与应用相同的地址、端口及认证条件，执行只读检查。命令中的地址是示例，已有 TLS 连接还应保留相应 TLS 和证书选项：

redis-cli -h redis.example.net -p 6379 --askpass ROLE
redis-cli -h redis.example.net -p 6379 --askpass INFO replication

有 ACL 用户时还需加实际的 --user。这些管理信息可能不向普通应用账号开放；出现 NOPERM 时，应请管理员查询，不能把权限错误当作主从状态。

ROLE 返回的第一个元素是 master、slave 或 sentinel。为协议兼容，即使新版本采用 replica 的叫法，返回值仍可能是 slave。INFO replication 的 role 字段提供相应判断；副本输出中的主节点地址与复制状态则用于核对来源。

若结果是副本，先与部署拓扑核对它是否本来就承担读流量。若结果是主节点，但应用仍报 READONLY，检查是否有多个后端、DNS 返回多个节点、连接池持有不同连接，或查询和错误发生在切换前后不同时间。一次 CLI 连接不能代表所有应用连接。

正常副本：改写入路由，保留只读保护

单独配置主从时，写请求应发送到已确认的主节点。将应用连接地址改到主节点，并按应用方式更新连接池；原本分开的读连接可继续访问副本。

不要设置 replica-read-only no 来让当前地址“恢复写入”。可写副本会产生仅属于本地的写入，不能作为主节点写入的替代；数据可能与主节点不一致，并在后续同步中被覆盖。也不要对一个正常副本执行 REPLICAOF NO ONE，它会改变拓扑。

修改前记录原连接配置、节点角色和预定的主节点。连接变更本身不会迁移数据。若新端点无法认证或访问，先检查网络、凭据和权限；回退也应指向拓扑中确认可写的节点，不能把旧副本地址当作稳定恢复目标。

Sentinel 切换后：客户端需要重新发现主节点

如果 Redis 由 Sentinel 管理，旧主节点可能在故障切换后成为副本。仍固定连接旧 IP 的程序随后写入，就会遇到 READONLY。

管理员可以向实际 Sentinel 端点查询当前主节点，下面的服务名和地址是示例：

redis-cli -h sentinel.example.net -p 26379 --askpass \
  SENTINEL get-master-addr-by-name app-cache

返回地址后还需到对应 Redis 节点检查 ROLE，并核对应用网络是否可达。没有返回地址、服务名错误或 Sentinel 不可达，应先解决发现链路，不从多个副本中任选一台写入。

应用应使用支持 Sentinel 的客户端配置，提供 Sentinel 地址和主服务名，重连时重新解析当前主节点。Sentinel 与数据节点的认证配置可能不同，不能只配置一处密码。

手工修改 IP 可以作为经过确认的临时恢复措施，但不能代替后续故障切换发现。连接池若保留旧连接，也需要按客户端支持的方式重建。写操作重试还要遵守业务幂等要求，尤其是计数、队列和支付状态等操作，不能在不确认结果的情况下无限重试。

计划只有一台 Redis，却意外成了副本

检查 Redis 的启动参数、实际配置文件、配置管理记录及角色变更时段的日志，寻找 replicaof、旧名 slaveof 或外部管理工具的角色调整。

若主节点地址不是部署预期地址，或日志显示未经授权的角色变更，应先限制访问并保留配置、日志和可用数据备份。公网可访问且认证不足的 Redis 存在被他人执行管理命令的风险，但 READONLY 本身不能证明入侵。

此时不应仅关闭只读或强制提升就宣告恢复：复制同步可能已改变数据，重启也不能证明数据可信。由负责该实例的人确认数据来源、备份完整性与恢复方案，再决定恢复独立节点或从可信备份重建。操作可能中断服务或覆盖数据，必须安排恢复窗口；证据不清楚时保留现场，避免执行清库、重同步或删除持久化文件。

成功标准需要覆盖应用的新连接

处理完成后，应用的新连接应落到部署确认的可写主节点，原业务写请求不再出现 READONLY；读连接、复制关系与高可用管理保持符合预定拓扑。

需要独立验证写入时，选择业务允许的隔离测试键并设置短 TTL，不覆盖现有键；验证后确认键按预期过期。只看 PING 返回 PONG 不足以证明写入端点正确，也不应为了这一检查关闭副本保护或触发生产故障切换。