Databases 31 min read

Understanding Redis Clustering: Replication, Sentinel, Codis, and Native Cluster Explained

This article explains Redis master‑slave replication, its configuration and failure handling, the automatic failover provided by Redis Sentinel, the proxy‑based Codis sharding solution, and the native Redis Cluster architecture, including slot hashing, redirection, and replica promotion.

Shepherd Advanced Notes
Shepherd Advanced Notes
Shepherd Advanced Notes
Understanding Redis Clustering: Replication, Sentinel, Codis, and Native Cluster Explained

1. Master‑Slave Replication

1.1 Concept

Master‑slave replication copies data from a Redis master node to one or more slave nodes. The data flow is unidirectional: writes go to the master, reads are served by slaves.

1.2 Why It Is Needed

Data backup – provides hot standby so a failed master can be replaced by a slave.

Load balancing – read‑write separation improves throughput.

High‑availability foundation – required for Sentinel and Redis Cluster.

1.3 Configuration

View replication status with info replication. To make a node a slave, run on the slave: slaveof <ip><port> Persist the setting by adding the line to redis.conf: slaveof 10.10.0.34 6379 Writes on the master are rejected on the slave:

127.0.0.1:6379> set a 123
(error) READONLY You can't write against a read only replica.

1.4 Replication Process

When a slave connects, it sends SYNC. The master forks a process to generate an RDB file and streams it to the slave (full sync). After the slave loads the RDB, the master continues to buffer subsequent write commands. The slave applies the buffered commands (incremental sync). The replication buffer is a fixed‑size circular array; if it overflows, older commands are lost and a snapshot sync is required.

1.5 Handling Disconnections

Before Redis 2.8 a network glitch caused a full resynchronization. Since 2.8 the master keeps a circular repl_backlog_buffer. After reconnection the slave sends PSYNC with its slave_repl_offset. If the master still has the missing commands, it sends only those (incremental); otherwise a full sync is performed.

If the slave was disconnected long enough that its offset was overwritten, a full sync occurs.

If the slave’s offset is still within the backlog, the master sends the missing commands, allowing incremental sync.

2. Sentinel Mode

2.1 What Sentinel Is

Sentinel is an independent process that continuously monitors master and slave instances. When the master fails, Sentinel automatically promotes the best slave to master, updates clients, and can re‑configure the former master as a slave after it recovers.

2.2 Message Loss

Replication is asynchronous, so a failing master may lose writes that slaves never receive. Sentinel cannot guarantee zero loss but can limit it with two parameters: min‑slaves‑to‑write 1 – the master stops accepting writes if fewer than one slave is replicating. min‑slaves‑max‑lag 10 – if a slave does not acknowledge within 10 seconds, the replication is considered abnormal.

2.3 Deployment and Usage

Run Sentinel in Docker:

docker run -d --name redis-sentinel -p 26379:26379 \
  -v /mydata/redis/conf/sentinel.conf:/conf/sentinel.conf \
  redis redis-sentinel /conf/sentinel.conf --sentinel

Sample sentinel.conf: sentinel monitor mymaster 10.10.0.18 6379 1 View logs with: docker logs -tf redis-sentinel SpringBoot test repeatedly writes a timestamp key and sleeps 5 seconds. When the master is killed, logs show the client reconnecting and, after about 36 seconds, Sentinel completes the failover and the service resumes.

spring:
  redis:
    sentinel:
      master: mymaster
      nodes: 10.10.0.34:26379
@SpringBootTest
@RunWith(SpringRunner.class)
public class RedisSentinelTest {
    @Resource
    private RedisTemplate redisTemplate;

    @Test
    public void test001() throws Exception {
        while (true) {
            String key = "time:" + new Date().getTime();
            redisTemplate.opsForValue().set(key, new Date().getTime(), 5, TimeUnit.MINUTES);
            TimeUnit.SECONDS.sleep(5);
            System.out.println(redisTemplate.opsForValue().get(key));
        }
    }
}

Log excerpt shows reconnection attempts and the moment Sentinel reports +switch-master. The interval from the first reconnection log (14:59:17) to the +switch-master log (14:59:53) is 36 seconds.

3. Codis

3.1 What Codis Is

Codis is a Go‑based proxy that speaks the Redis protocol. It forwards client commands to a set of Redis instances, forming a logical cluster.

3.2 Sharding Principle

Keys are mapped to 1024 slots (configurable). The proxy computes crc32(key) % 1024 to obtain the slot, then forwards the command to the Redis instance assigned to that slot. Slot‑to‑instance mappings are stored in ZooKeeper and can be observed/modified via a dashboard.

3.3 Scaling and Data Migration

When a new Redis node is added, slots are re‑balanced. Codis provides a SLOTSSCAN command to enumerate all keys in a slot, then migrates each key individually. During migration, a request for a migrating key is first migrated to the new node before being processed.

Codis also offers automatic balancing: idle periods trigger inspection of slot distribution and, if uneven, automatic migration of slots to achieve balance.

3.4 Limitations

Multi‑key transactions are unsupported because keys may reside on different nodes. rename across slots is unsafe.

Large values (e.g., hashes > 1 MiB) can cause migration stalls; splitting large collections is recommended.

The extra proxy layer adds network overhead, which can be mitigated by adding more proxy instances.

Using ZooKeeper for slot metadata introduces operational cost.

4. Redis Cluster

4.1 Overview

Redis Cluster is the official, decentralized clustering solution. It hashes keys with CRC16 and maps them to 16384 slots. Each node manages a subset of slots and communicates with peers via a binary protocol.

4.2 Slot Tagging and Redirection

Clients can force a key into a specific slot using a tag in the key name. If a client contacts a node that does not own the key’s slot, the node replies with -MOVED slot host:port. The client updates its slot table and retries the request on the correct node.

During migration, a node may reply with -ASK host:port. The client first sends an ASKING command to the target node, then reissues the original command.

4.3 Failover

Each master can have replicas. If a master fails, a replica is promoted automatically. If a master has no replicas, the cluster becomes unavailable unless the cluster-require-full-coverage option is disabled, allowing partial operation.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

High AvailabilityRedisreplicationSentinelCodisRedis Cluster
Shepherd Advanced Notes
Written by

Shepherd Advanced Notes

Dedicated to sharing advanced Java technical insights, daily work snippets, and the power of persistent effort.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.