SQLly logoSQLly

Redis Cluster

functional

Redis Cluster, ElastiCache cluster mode and MemoryDB: slot routing, a node map for unreachable node addresses, per-node SSH forwards, and topology.

SQLLY connects to Redis Cluster - self-hosted clusters, Amazon ElastiCache in cluster mode, and Amazon MemoryDB - and routes every command to the node that owns its key's hash slot. When the cluster moves a slot (a failover or a reshard), the client follows the MOVED or ASK reply, updates its slot map, and tells you how many redirects a script saw. The key browser, the memory analyzer, bulk actions, the Profiler and the Pub/Sub viewer all work across every master.

Connecting

Create a Redis connection as usual. In Server you can list several seed nodes, comma-separated (10.0.0.1:7000, 10.0.0.2:7001); an entry without a port uses the Port field. Pasting a URL such as redis://user:[email protected]:7000,10.0.0.2:7001 keeps every host. Under Cluster mode pick:

  • Detect automatically (the default) - the first connect asks the server INFO cluster and remembers the answer until you quit, so a single server pays for one extra probe per session and nothing else changes.
  • Single server - never route by slot, even if the server is a cluster node.
  • Redis Cluster - always route by slot.

A cluster has one logical database, so leave Database blank or set it to 0. For ElastiCache, point the connection at the cluster's configuration endpoint; MemoryDB is always a cluster.

Node map: when nodes advertise addresses you cannot dial

Cluster nodes tell clients where the other nodes are, using the addresses they were configured to announce. Behind NAT, a Docker port mapping or an SSH bastion those are often private addresses this machine cannot reach. The Cluster node map field rewrites them: one advertised host:port => dial host:port per line, for example 10.0.0.5:7001 => 127.0.0.1:17001. The advertised address keeps naming the node (in the slot map, in redirects, and as the TLS server name); only the socket goes to the dial address.

SSH tunnels and proxies reach every node. On a connection with SSH hops or a SOCKS/HTTP proxy, SQLLY opens a separate local forward for each node the cluster names, through the same hops, so a node address only the bastion can reach still works. The node map is applied first, so it can also rewrite what the bastion dials. A Kubernetes port-forward carries one service port, so it can reach only the seed node, and connections through a relay bridge do not support cluster mode yet.

What the editor refuses on a cluster

Each command is refused before it is sent, with a message that names the rule:

  • Multi-key commands across slots - MGET, MSET, DEL with several keys, SUNION, RENAME, EVAL with several keys and the like run only when every key maps to the same slot. Give related keys a common hash tag: user:{42}:profile and user:{42}:cart share a slot.
  • SELECT of anything but 0 - a cluster has one logical database.
  • KEYS and SCAN - KEYS would block every master, and a SCAN cursor belongs to one node. Use the key browser, or SQLLY.KEYS pattern [limit [cursor]], which walks every master in pages and returns a cursor that continues across them.
  • MULTI / EXEC - each command is routed on its own, so a transaction cannot stay on one node from the editor.

When the client followed redirects while a script ran, the Messages pane says how many (for example after a failover). That is normal right after the cluster moves slots; a steady stream of redirects points at a resharding in progress.

Tools across the whole cluster

  • Key browser - lists keys from every master in turn, up to its usual budget; when it stops early the note row says how many keys it scanned across how many masters, and Scan more continues on the node where it stopped.
  • Memory Analyzer - the sample is split between masters in proportion to each one's key count, and the total is summed across them.
  • Bulk delete - the matched keys are grouped by hash slot so every UNLINK batch stays inside one slot.
  • Profiler - runs MONITOR on every master at once and merges the streams into one table with a node column.
  • Pub/Sub viewer - keyspace notifications are subscribed on every master (they are per node), ordinary channels and patterns on one master (a cluster delivers PUBLISH everywhere), and sharded channels - enter them with a leading #, such as #orders - on the master that owns each channel. Rows carry a node column. Sharded channels also work on a standalone Redis 7 server.

Cluster Topology

Right-click a Redis database and choose Tools › Cluster Topology…, run Redis Cluster Topology… from the command palette, or use the link on the Server Dashboard of a cluster connection. The pane lists every node from CLUSTER SHARDS (or CLUSTER NODES on servers before 7.0): its id, role, the address it advertises, the address SQLLY dials for it, its announced hostname and the TLS server name the client sends, its slots, health, replication offset and link state. The footer counts masters and replicas, checks that all 16,384 slots are covered, and names any node that is not healthy or is dialed at another address than it advertises.

Trace runs the same step-by-step check as Test Connection against each node - name lookup, tunnel or proxy (with the node map), TCP, TLS (checked against the address the node announces), sign-in, protocol and ping, database, and CLUSTER INFO - one row per step, so the first failing row tells you what to fix: a wrong node map entry, a blocked port, a TLS name mismatch, an ACL problem, or a node that does not report a healthy cluster. Both reports are also available as SQLLY.TOPOLOGY and SQLLY.TRACE in a query tab; they only read.