sharded_redis_cluster_behavior.md

Sharded Redis Cluster Behavior

Provision Sharded Redis Cluster using Docker Compose

$ curl -sSL https://raw.githubusercontent.com/bitnami/bitnami-docker-redis-cluster/master/docker-compose.yml > docker-compose.yml
$ docker-compose up

Write sample dataset

$ docker exec -ti redis_cluster_redis-node-0_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c'
172.18.0.3:6379> set key1 value1
OK

172.18.0.3:6379> set key2 value2
-> Redirected to slot [4998] located at 172.18.0.7:6379
OK

172.18.0.7:6379> set key3 value3
OK

172.18.0.7:6379> set key4 value4
-> Redirected to slot [13120] located at 172.18.0.6:6379
OK

172.18.0.6:6379> set key5 value5
-> Redirected to slot [9057] located at 172.18.0.3:6379
OK

172.18.0.3:6379> set key6 value6
-> Redirected to slot [4866] located at 172.18.0.7:6379
OK

172.18.0.7:6379> set key7 value7
OK

172.18.0.7:6379> set key8 value8
-> Redirected to slot [13004] located at 172.18.0.6:6379
OK

172.18.0.6:6379> set key9 value9
-> Redirected to slot [8941] located at 172.18.0.3:6379
OK

Master Nodes are 3, 4, 5. Slave Nodes are 0, 1, 2.

$ docker exec -ti redis_cluster_redis-node-0_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c info' | grep 'role:'
role:slave

$ docker exec -ti redis_cluster_redis-node-1_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c info' | grep 'role:'
role:slave

$ docker exec -ti redis_cluster_redis-node-2_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c info' | grep 'role:'
role:slave

$ docker exec -ti redis_cluster_redis-node-3_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c info' | grep 'role:'
role:master

$ docker exec -ti redis_cluster_redis-node-4_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c info' | grep 'role:'
role:master

$ docker exec -ti redis_cluster_redis-node-5_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c info' | grep 'role:'
role:master

Commands that touches keys hosted at multiple slots (master nodes) always fails

• EXISTS key1 key2
• MGET key1 key2
• MSET key1 value1 key2 value2
• MSETNX key1 value1 key2 value2
• TOUCH key1 key2
• DEL key1 key2
• SDIFF key1 key2
• MULTI, GET key1, GET key2, EXEC

$ docker exec -ti redis_cluster_redis-node-3_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c'

172.18.0.3:6379> exists key1
(integer) 1

172.18.0.3:6379> exists key1 key2
(error) CROSSSLOT Keys in request don't hash to the same slot

172.18.0.6:6379> mget key1
-> Redirected to slot [9189] located at 172.18.0.3:6379
1) "value1"

172.18.0.6:6379> mget key1 key2
(error) CROSSSLOT Keys in request don't hash to the same slot

172.18.0.3:6379> mset key1 value1
OK

172.18.0.3:6379> mset key1 value1  key2 value2
(error) CROSSSLOT Keys in request don't hash to the same slot

172.18.0.6:6379> touch key1
-> Redirected to slot [9189] located at 172.18.0.3:6379
(integer) 1

172.18.0.6:6379> touch key1 key2
(error) CROSSSLOT Keys in request don't hash to the same slot

172.18.0.3:6379> del key1
(integer) 1
172.18.0.3:6379> del key1 key2
(error) CROSSSLOT Keys in request don't hash to the same slot

172.18.0.3:6379> multi
OK
172.18.0.3:6379> get key1
QUEUED
172.18.0.3:6379> get key2
-> Redirected to slot [4998] located at 172.18.0.7:6379
(nil)
172.18.0.7:6379> exec
(error) ERR EXEC without MULTI

KEYS, SCAN commands return dataset only for current master

• Both KEYS and SCAN has the same behavior, below an example for KEYS
• Client must repeat same command for each Master Node in a cluster
• WARN. Developer who are no aware on this won't see an error and keep working with an incomplete dataset

$ docker exec -ti redis_cluster_redis-node-3_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c keys "*"'
1) "key8"
2) "key4"

$ docker exec -ti redis_cluster_redis-node-4_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c keys "*"'
1) "key1"
2) "key5"
3) "key9"

$ docker exec -ti redis_cluster_redis-node-5_1 bash -c 'REDISCLI_AUTH=bitnami redis-cli -c keys "*"'
1) "key6"
2) "key7"
3) "key2"
4) "key3"