Competitor watch: Redis clusters and Sentinel
Twelve Redis Insight, DbGate and Chat2DB reports on clusters, Sentinel and restricted users checked against SQLly: one bug fixed, two features built.
Today's theme is Redis deployments that are more than one box: clusters behind SSH forwards, clusters that announce hostnames, clusters whose nodes move, replicas nobody can see, Sentinel setups that can't be written down as config, and the humble user who isn't allowed to run INFO. Twelve reports from Redis Insight, DbGate and Chat2DB, between nineteen days and nearly three years old. SQLly already had four, was checked and safe on five, had one ourselves (the INFO one, fixed today), built two features people have been asking for since 2023, and one doesn't apply to how we ship.
Cluster - random selection of endpoints to execute command against — Redis Insight
Opened 2 years, 11 months ago; last maintainer reply 7 months ago, which said a PR would be reviewed. Five reactions and six comments. Matiszak wants to pick a node, any node, and run a command there, like redis-cli without -c. Skoucail pointed out that version 1 could do this and version 2 can't, a maintainer replied that it wasn't prioritized, mquinnfd added that flushing every node of a cluster is now impossible, and two years later Matiszak offered to build it themselves. A feature that went missing in an upgrade and came back as an invitation to contribute. SQLly now has SQLLY.ON masters FLUSHALL, SQLLY.ON replicas DBSIZE and SQLLY.ON 10.0.0.4:7003 INFO replication, with one row per node and the usual write confirmations, plus a Query on Node button in the Cluster Topology view. Built today.
Cluster do not see slave nodes — Redis Insight
Opened 2 years, 8 months ago; last maintainer reply 2 years, 8 months ago, asking why anyone needs to monitor replicas. One reaction and four comments. jakub-kubera only sees masters, vajradhar noted that 1.x used to show them, jakub-kubera answered the "why" with a paragraph about sync state, failover and resharding, and Skoucail agreed they used the failover button all the time. The question got its answer; the answer got silence. SQLly's Cluster Topology view lists every replica with its master, replication offset, link state and health; there's no failover button yet. Already have it.
Not all nodes are shown (2.52.0) — Redis Insight
Opened 2 years, 3 months ago; last maintainer reply 2 years, 2 months ago ("can you try 2.54?"). One reaction and four comments. Samox1 runs a cluster on a Slurm allocation and Redis Insight reports "Primary nodes - 1" while redis-cli counts all of them; Skoucail came back a year later with screenshots saying it still happens on 2.68. Sixteen minor versions later, the cluster is still a cluster of one. We checked: SQLly's topology view builds its list from what the cluster itself reports, every node, and a test pins three masters and three replicas against a real CLUSTER NODES reply. Checked, not affected.
cluster - no rediscover cluster nodes — Redis Insight
Opened 2 years, 2 months ago; the maintainers' last word, 8 months ago, was "Noted ✍️". No reactions, three comments. raphaelauv changed the nodes in a cluster and had to create a fresh copy of the same connection to see them. Eighteen months later a templated cleanup message asked whether it was still valid; raphaelauv said yes within six minutes. Responsiveness is clearly not the reporter's problem. We checked: SQLly never saves a cluster's node list; it reads it fresh on every connection, follows slot moves as they happen, and the topology view's Refresh asks again. Checked, not affected.
Cannot configure sentinel via ENVVARS — Redis Insight
Opened 1 year, 3 months ago; last maintainer reply 8 months ago, which was reopening it after their own stale-bot closed it. No reactions, five comments. jeremych1000 wants Sentinel as config-as-code, and found the only route is to click it together in the UI, export JSON, and then discover the passwords can't be injected. fxrobin-capg tried both env vars and the JSON file and got nothing in the UI, then rescued the issue from auto-close after a week off. The issue survives on the strength of one person's out-of-office timing. SQLly can now start with connections from a provisioning file or one SQLLY_CONNECTION_<NAME> variable each, including redis+sentinel:// URLs with several sentinels and a master name, and a password written as ${VAR} is read from the environment at connect time instead of being copied anywhere. Built today.
Bulk delete completely broken with Redis Sentinel setup — Redis Insight
Opened 1 year, 2 months ago; no maintainer reply, ever. No reactions, three comments. momszx selected keys, pressed delete, and watched the network tab do nothing. Then they narrowed it down to the proxy path setting, and pavel-shir found the line of config responsible and a workaround. The users debugged it to the line; the line is still there. We checked: SQLly's bulk delete sends UNLINK batches straight to the master Sentinel names, and there's no web socket path to get out of sync. Checked, not affected.
Specifying multiple hosts for single cluster entry — Redis Insight
Opened 9 months ago; last maintainer reply 9 months ago, "tracked in our backlog… no ETA". No reactions, two comments. Matiszak again, this time asking that a cluster connection not die just because the one host it names is down. A reasonable ask, politely made, parked in a "broader initiative". In SQLly the Server field of a Redis connection takes several seed hosts separated by commas, and any one that answers is enough. Already have it.
Supports access via FQDN/Hostnames — Redis Insight
Opened 9 months ago; last maintainer reply 8 months ago. No reactions, five comments. frank2ch can't reach a sharded OCI Cache cluster because it announces hostnames, asked for an update, got "no updates", was told to try a server setting, and explained that the managed service doesn't allow it. We checked: SQLly reads announced hostnames from the cluster's slot and shard replies and dials them as given, and the topology view shows the name each node announced next to the address actually used. Checked, not affected.
Redis Cloud autodiscovery imports databases without TLS → read ECONNRESET — Redis Insight
Opened 4 months, 3 weeks ago; a maintainer replied the same day with "we'll take a look 👍", and that's the last we've heard. One reaction, two comments. marcinkubica wrote the kind of bug report teams frame and hang on the wall, down to the module path, and noted the TLS part has no test coverage across three versions. SQLly has no Redis Cloud account discovery, so there's nothing to compare; our Redis Insight importer does carry TLS, CA and client certificates across, with a test whose name is literally "TLS is never dropped". Not applicable.
SSH-locally forwarded port does not work — Redis Insight
Opened 19 days ago; no maintainer reply yet, but it's young. No reactions or comments. MikeAski forwarded a three-node cluster to local ports and got "Failed to refresh slots cache", because the nodes keep announcing their remote addresses. The youngest issue in the batch and already an old story. SQLly's Redis connections have a cluster node map (10.0.0.5:7001 => 127.0.0.1:17001) that rewrites each announced address to the one you forwarded, and connections through SSH get a forward per node automatically. Checked, not affected.
BUG: Redis Connect failed — DbGate
Opened 7 months ago; no vendor reply, ever. No reactions or comments. sudo-tenb has an ElastiCache user that isn't allowed to run INFO, and DbGate's connect fails on exactly that. Seven months of quiet; at least the stack trace is tidy. Here's the honest part: SQLly connected fine, but expanding the server or opening the Databases view then failed for the same reason, because we read key counts from INFO keyspace. Today SQLly lists every database anyway and leaves the counts blank rather than pretending they're zero. Bug we had, fixed.
不支持Redis的json数据 — Chat2DB
Opened 2 months, 2 weeks ago; the only reply is from a bot asking for more detail. No reactions, one comment. like0121 can't open RedisJSON values in Chat2DB and filled in "Actual behavior" with "ok", which is a mood we've all had. SQLly opens JSON keys with JSON.GET in the key view and hands them to the JSON viewer as a tree. Already have it.