redis-cli --cluster: Manage Redis Cluster in CI

redis-cli --cluster create wires standalone redis nodes into a Redis Cluster, assigning hash slots and replicas in one command.

Testing cluster-aware code needs a real cluster. redis-cli --cluster builds one from a set of redis-server instances started with cluster mode enabled.

What it does

redis-cli --cluster manages Redis Cluster from the CLI. create joins a list of host:port nodes into a cluster and distributes the 16384 hash slots; --cluster-replicas sets how many replicas each primary gets. check and info inspect an existing cluster's slot coverage and health.

Common usage

Terminal

# build a 6-node cluster (3 primaries, 1 replica each)
redis-cli --cluster create \
  127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1 --cluster-yes
redis-cli --cluster check 127.0.0.1:7000
redis-cli -c -p 7000 cluster info

Options

Flag / subcommand	What it does
--cluster create <nodes>	Create a cluster from the listed host:port nodes
--cluster-replicas <n>	Replicas per primary
--cluster-yes	Accept the proposed slot layout non-interactively
--cluster check <node>	Verify slot coverage and node health
--cluster info <node>	Summarize the cluster state
-c	Follow MOVED/ASK redirects in client mode

In CI

Pass --cluster-yes so create does not wait for a y/n at the slot-assignment prompt. The nodes must already be running with cluster-enabled yes and distinct ports; create only joins them. After create, poll cluster info for cluster_state:ok before running tests, since slot assignment and gossip take a moment.

Common errors in CI

"[ERR] Node 127.0.0.1:7000 is not empty" means a node already holds keys or cluster config; flush and reset it first. "Not all 16384 slots are covered" from check means create did not finish or a node is down. "CLUSTERDOWN Hash slot not served" at query time means cluster_state is not yet ok; wait for it. Without -c, a client gets MOVED errors instead of following redirects.