This error occurs when your application attempts a write operation on a Redis replica instead of the primary master node. Redis replicas are read-only by default to prevent accidental data corruption.
Fixes READONLY You can't write against a read only replica
redis-cli
> INFO REPLICATIONredis-cli> INFO REPLICATIONREADONLY You can't write against a read only replica
In a Redis replication setup, the primary node (master) handles all write operations while replica nodes sync data and serve read-only requests. When you try to write to a replica, Redis rejects the command with this error. This is a safety mechanism because replicas should only mirror the master's data, not create independent modifications that would cause inconsistency.
Connect to your Redis instance and check its role:
redis-cli
> INFO REPLICATIONLook for the role field. If it shows role:slave, you're on a replica. If it shows role:master, the replica-read-only setting is the issue.
Get the master node's address from the replica:
> INFO REPLICATION
master_host:127.0.0.1
master_port:6379Note the master's host and port. You should connect your application here for write operations.
Change your Redis client to connect to the master node's address:
Node.js example:
const redis = require('redis');
const client = redis.createClient({
host: 'master-node-ip', // Use master, not replica
port: 6379
});Python example:
import redis
r = redis.Redis(host='master-node-ip', port=6379, db=0)Verify with a test write:
r.set('test-key', 'value')If using AWS ElastiCache, Google Cloud Memorystore, or Azure Cache:
1. Open your Redis service console
2. Find the primary/master endpoint (not read-replica endpoint)
3. Update your application configuration to use this endpoint
Example AWS ElastiCache:
- Use: my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com:6379
- NOT: my-redis-replica.abc123.ng.0001.use1.cache.amazonaws.com:6379
Only do this if the original master is permanently down and you understand the implications:
redis-cli
> SLAVEOF NO ONEThis makes the replica a standalone master. Use with caution as you may lose recent writes if the original master was still running.
If using Redis Sentinel or Cluster mode:
For Sentinel:
- Connect to sentinel port (26379) and query for master
- Let the client library handle master discovery
- Ensure your client supports sentinel protocol
For Cluster:
- Use a cluster-aware client library
- Set cluster-enabled yes in redis.conf only on cluster nodes
- Let the client discover all nodes and send writes to slots' owners
Connection pooling tip:
// Bad: Creates new connection per request
const client = redis.createClient({host: 'master'});
// Good: Reuse connection pool
const pool = redis.createPool({host: 'master', max: 10});Replica Read-Only Mode: The replica-read-only config parameter (default: yes) controls whether replicas reject writes. You can disable it with CONFIG SET replica-read-only no at runtime, but this is NOT recommended because writable replicas create consistency issues.
DNS and Connection Caching: Some Redis clients cache DNS results or connection objects. If your master changes, the cache may still point to old nodes. Solutions: disable DNS caching in your client, use Redis Sentinel for automatic failover, or implement application-level health checks.
Failover and Retry Logic: After failover, client libraries might retry failed commands on random nodes (including replicas). If a write command times out during failover, the retry might hit a replica, causing this error. Use client libraries with master-aware retry logic.
Cluster vs Replication: In Redis Cluster mode, each slot has a master and replicas. Writes must go to the slot's master. The readonly command allows a client to read from replicas, but writes always fail on replicas even with it enabled.