Replication, Sentinel and Cluster

Key points

• Replication is asynchronous by default, so a write acknowledged by the primary can be lost if it fails over immediately.
• A replica is read-only because replica-read-only defaults to yes, and it serves stale-by-milliseconds data.
• WAIT numreplicas timeout blocks until that many replicas confirm, which reduces the window but is not a commit protocol.
• Sentinel processes monitor the primary, agree on failure by quorum and promote a replica; run at least three of them.
• Cluster shards the keyspace into 16384 hash slots chosen by CRC16 of the key, and only database 0 exists.
• Multi-key commands in Cluster need all keys in one slot, which is what hash tags such as {user:1000} are for.

Example

# --- Sentinel: same dataset, automatic failover, port 26379
sentinel monitor mymaster 10.0.0.11 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000

# --- Cluster: sharded keyspace, 16384 slots
$ redis-cli --cluster create 10.0.0.11:6379 10.0.0.12:6379 10.0.0.13:6379 \
            10.0.0.14:6379 10.0.0.15:6379 10.0.0.16:6379 \
            --cluster-replicas 1   # 3 masters + 1 replica each = 6 nodes minimum
$ redis-cli -c -p 6379 GET product:991
-> Redirected to slot [9866] located at 10.0.0.12:6379

# keys that must share a slot use a hash tag
MSET {user:1000}:name Ada {user:1000}:email ada@x.io

Sentinel keeps one dataset available; Cluster splits the dataset - choose by whether memory or uptime is the limit.