According to the cluster specification:
Redis Cluster implements all the single key commands available in the non-distributed version of Redis. Commands performing complex multi-key operations like Set type unions or intersections are implemented as well as long as the keys all belong to the same node.
But I'm seeing CROSSSLOT errors when running these types of commands on a single node cluster. The code enforces that all keys must hash to the same slot. Are the docs wrong? Should it say that the keys must belong to the same slot? Or can the requirement in the code be relaxed to allow keys from different slots, as long as they are on the same shard?
Comment From: mgravell
Slots, not shards, are the safe unit; shards are an implementation detail that client libraries need to know about, but calling code needs to be slot safe. The reason is: the point is that slots should be free to migrate between shards as required, to balance load. If the server allowed you to perform cross-slot operations as long as it resolved to the same shard, this would be a bomb - you'd have code that works today because of an accident of how the slots are distributed between shards but that can break when an admin very legitimately migrates some of the slots to another shard.
So, to prevent this: cross-slot operations are simply disallowed. The calling code should make use of "hash tags" (i.e. keys like "{something shared}/foo" and ""{something shared}/bar") to ensure that related keys (that may need to be involved in a multi-key operation) are always located on the same slot.
If you only have a single-shard cluster... it kinda feels like you shouldn't be using cluster mode, but traditional server mode. That would also be a pragmatic fix here :)
Comment From: jeffjo
Thanks for the explanation. Looks like I'm not the only one who was confused by the docs.
Regarding why we're using a single-node cluster, it's actually pretty silly. We're using AWS-managed Redis (Elasticache) and in order to set up the cluster for HA, you must configure it to be in cluster mode, but only if you're using T2 class (the least expensive) nodes.
The M3.medium is the least expensive node type that supports HA without the cluster-mode requirement, but it is over 5x more expensive than the T2.micro, which has more than enough CPU/memory for our use case.
Comment From: itamarhaber
@jeffjo the docs are indeed wrong - would you care to make a PR to https://github.com/antirez/redis-doc that fixes this fallacy?
Comment From: itamarhaber
Closing as docs PR was merged.