Fix: READONLY You can't write against a read only replica

This error means your application sent a write command (SET, DEL, EXPIRE, anything that mutates data) to a Redis replica, and the replica refused because replicas are read-only by design. Reads keep working, so the app half-works in a confusing way: sessions read fine but do not update, queues drain but do not fill. The replica is behaving correctly. The problem is that your writes are being routed to the wrong node, and the most common trigger is a failover your clients never followed.

READONLY You can't write against a read only replica

What this error means

In Redis replication one node is the master, accepting writes and streaming them to replicas, which serve reads. replica-read-only yes is the default because a write applied to a replica exists nowhere else and is wiped by the next resynchronization, so Redis rejects such writes with this error rather than losing them silently. Getting this error therefore means a topology and routing disagreement: your client believes this node is the master, and the node knows it is not. Either a failover changed the topology while client configuration stood still, or the connection string pointed at a replica from the start.

Common causes

• A failover happened (Sentinel, cluster, or managed service maintenance): the master moved, and clients still hold connections or configuration pointing at the demoted node.
• The application is configured with a replica’s address, or with a load balancer or DNS name that spreads connections across all nodes including replicas.
• Long-lived connection pools that never re-resolve DNS, so a moved primary endpoint keeps resolving to the old node inside the pool.
• A Redis Cluster client that does not handle redirection properly and lands write commands on the wrong node.
• Someone manually promoted or demoted nodes and application configuration was never updated.

How to fix it

STABILIZE first. Find the real master and point the application at it. This restores writes immediately even before you fix the discovery mechanism.

redis-cli -h <node> INFO replication | head -5

1. DIAGNOSE the topology. Run the same INFO against each node, or ask Sentinel for the authoritative master address.

redis-cli -h <sentinel-host> -p 26379 \
  SENTINEL get-master-addr-by-name mymaster

The node your app writes to should report role:master. If it says role:slave, your routing is the whole problem.

2. FIX the client configuration according to your setup. With Sentinel, applications must connect through Sentinel discovery, not to a fixed node. For example with a typical client:

# Connect via Sentinel, not a node address
sentinels: sentinel-1:26379, sentinel-2:26379, sentinel-3:26379
master_name: mymaster

3. With a managed service (ElastiCache, Azure Cache, Memorystore), use the primary endpoint the provider publishes, which follows failovers, and never individual node endpoints for writes. After a failover, restart or refresh connection pools so cached DNS results and open sockets to the old primary are dropped.

kubectl rollout restart deployment/myapp

4. If reads should go to replicas, do it deliberately with a client that splits reads and writes, rather than a load balancer mixing all nodes into one pool. Writes always go to the master; reads may go to replicas if stale-by-milliseconds data is acceptable.

5. Verify by watching for the error to stop and confirming writes land on the master.

redis-cli -h <master> MONITOR | head -20

Use MONITOR only briefly, since it is expensive on busy instances.

How to prevent it

• Never hardcode individual Redis node addresses in applications; always use Sentinel discovery, cluster-aware clients, or the provider’s primary endpoint.
• Make connection pools respect DNS TTLs or subscribe to failover events, so a promotion propagates without restarts.
• Test failover on purpose in staging: kill the master and confirm writes recover without human intervention.
• Alert on the READONLY error rate in application logs, which is the earliest signal that clients missed a failover.
• Keep replica-read-only yes; treat any suggestion to disable it as a design smell.
• Document the topology and who moves it, so manual promotions always come with a configuration change.

When to call a senior engineer

Call for help when failovers keep leaving parts of the fleet writing to a demoted node, when the client library’s topology handling is a black box nobody trusts, or when you suspect writes were lost during the confusion and need to know what. Erzon engineers can audit the discovery path from application to Redis, fix the failover behavior end to end, and prove with a controlled failover test that the next promotion will be a non-event.