mithril

Compatibility

The 98-test integration suite runs against each backend, in every mode combination (backend-sharding, reply-cache), with full cluster teardown/recreate between versions; it includes a live slot migration (CLUSTER SETSLOT MIGRATING/IMPORTING + MIGRATE) under multi-key commands and, on Redis 8.4+ and Valkey 9, an atomic slot migration (CLUSTER MIGRATION IMPORT / CLUSTER MIGRATESLOTS) moved back and forth under a single-key write stream, which must see no error and lose no increment:

backend	server version	result
redis:6.2	6.2.24	pass
redis:7.4	7.4.11	pass
redis:8.2	8.2.9	pass
redis:8.10	8.10.1	pass
valkey/valkey:9.1	9.1.2	pass
redis-stable (source)	8.10.1	pass

Clients verified: redis-py (cluster and standalone mode), redis-cli, memtier_benchmark, redis-benchmark.

Known limitations

• ACL: users, passwords, command/category/subcommand rules, key and channel patterns, ACL LOG. Command rules apply per subcommand as in Redis 7 (+@all -@dangerous removes ACL SETUSER and CONFIG SET; +cmd|sub and -cmd|sub both work). Not supported: selectors, ACL LOAD/SAVE (no ACL file), the sanitize-payload flags, and CONFIG SET requirepass at runtime. ACL GETUSER and ACL LOG use the Redis 6.2 reply shapes; GETUSER renders command rules in canonical form (-@all +@cat... +cmd... +cmd|sub).
• MULTI queues key-addressed commands only (EVAL/PING inside MULTI are rejected; real Redis queues them). WATCH keys and the transaction that follows must share one slot, and a multi-key command spanning the watched slot and others is refused while the watch is held; UNWATCH inside MULTI answers OK at once instead of being queued.
• SELECT n (Valkey 9 cluster-databases) binds the session to connections that selected that database; the reply cache serves database 0 only, and SWAPDB and MOVE across databases are the servers’ own affair per node.
• Aggregate replies to RESP3 clients keep RESP2 shape (flat arrays, not maps); every mainstream client parses by wire type and accepts this.
• Pubsub delivery to a slow subscriber is windowed (4096 pushes).
• Config hot-reload covers loglevel, acl-pubsub-default, acllog-max-len and the two slowlog-* keys; CONFIG SET rejects every other parameter.
• SCRIPT KILL, SCRIPT DEBUG and FUNCTION KILL are not proxied. The transparent reload on NOSCRIPT covers scripts the proxy loaded itself, redirected or not, and only while nothing later from the same session is in flight (a pipelined EVALSHA gets the NOSCRIPT and the client’s own EVAL fallback applies). FUNCTION commands reach the masters that own slots; a node needs its libraries loaded before slots move to it, as with any client.
• Shard pubsub: the shard channels of one client connection must live on one node (the node its pubsub connection reaches), as with a direct cluster connection; a channel elsewhere is refused with an error rather than a redirect.
• Blocking commands (BLPOP, BRPOP, BRPOPLPUSH, BLMOVE, BLMOVEM, BLMPOP, BZPOPMAX, BZPOPMIN, BZMPOP, blocking XREAD) always run on the slot’s master and never use replica routing.
• FLUSHDB and cluster-wide KEYS are not implemented; RANDOMKEY samples one random master’s keyspace, not the whole cluster.
• Multi-key commands with single-node semantics (MSETNX, RENAME, SMOVE, BITOP, the *STORE family, …) route by their first key; the owning node enforces same-slot, exactly as a direct cluster connection would.
• PFCOUNT over keys in different slots sums the per-slot cardinalities (elements present in several slots count more than once); within one slot it is the server’s exact union.
• During a slot migration a same-slot MSET or DEL that the server refuses with TRYAGAIN is retried whole once the handoff settles (2 ms, doubling, up to six waits), so under an atomic migration it stays atomic; only a legacy migration whose keys really sit on two nodes still executes it as independent single-key commands, which a concurrent reader can observe half applied. A redirect that outlasts the waits ends it with TRYAGAIN.
• After a failover a cluster-wide write (FLUSHALL, FUNCTION LOAD) can reach a demoted node and be answered READONLY; the proxy then refreshes the topology and resends it to the new master of that shard only, up to six times with short waits, and only a refresh slower than that leaves the client the READONLY. The session waits for the outcome before it runs the client’s next command.
• Server-management commands are not proxied: WAIT, DEBUG, LATENCY, MEMORY, SHUTDOWN, FAILOVER, REPLICAOF, SAVE/BGSAVE, MIGRATE and similar return unknown-command. OBJECT routes by its key.
• CLIENT supports ID, SETNAME, GETNAME and LIST (id, addr, fd, name, age, cmd).
• No TLS, no unix-domain listener, no keyspace notifications, no Prometheus endpoint (stats via INFO).

mt-proxy features not carried over

The mt-proxy functional suite exercises a proxy-specific surface that mithril does not reproduce; each returns unknown-command or an unsupported CONFIG parameter, never a silent approximation:

• node- and slot-addressed commands: NODESCAN, NODESSCAN, NODEHSCAN, NODEZSCAN, SLOTSCAN, FLUSHNODE (address the node directly instead);
• PROXY INSPECT / CONNECTION LIST / MEMORY PURGE / CPU REBIND / CACHE ADD|PADD|DELETE|PDELETE|PLIST, and the opt-in local-cache strategy with its local_cache_* INFO fields (the reply cache is reply-cache yes, reported as cache_*);
• COMMAND SUPPORT ADD/DELETE/LIST: the command table is generated at build time from the servers’ own COMMAND INFO;
• PAUTH and redis-user / redis-pass: backend credentials come from the config file (backend-auth-user, backend-auth-pass);
• CONFIG SET of worker-threads, proxy-redis-conn, proxy-slave-mode, readonly, protected-mode, maxclients, requirepass, timeout, tcp-backlog, tcp-keepalive, client-query-buffer-limit at runtime;
• CLUSTER NODES listing the backend nodes: the proxy presents itself as one virtual node owning every slot.

This site is open source. Improve this page.