SQLly logoSQLly

Sentinel

functional

Connect through Redis Sentinel by master name, read from replicas, and survive failovers.

A Redis or Valkey deployment run by Sentinel moves its master when the old one fails. Instead of a fixed host, a Sentinel connection gives SQLly the master name the sentinels watch and a list of sentinels to ask. Every time SQLly connects it asks the sentinels, in order, for the current master (SENTINEL GET-MASTER-ADDR-BY-NAME), checks that the server it reaches really is a master, and connects there. A sentinel that is down, or that still names the old master during a failover, is skipped and the next one is asked.

Setting it up

In the connection editor pick Redis (or Valkey) and turn on Connect through Sentinel. Fill in:

  • Master name - the name in the sentinels' sentinel monitor line, often mymaster.
  • Sentinels - a comma-separated list such as 10.0.0.1:26379, 10.0.0.2:26379, 10.0.0.3:26379. A host without a port uses 26379; write IPv6 addresses as [::1]:26379.
  • Sentinel password - only when the sentinels themselves require one (requirepass on the sentinel). It is kept in the system keychain like your other passwords.

The user name and password in the main form sign in to the master (and to replicas), as on a direct connection; the logical database and TLS mode apply to them too, and the sentinels are reached with the same TLS mode. The Host and Port fields are not dialed for data: if you leave Host blank, SQLly shows the first sentinel there.

Press Test and the result names the master that answered and the sentinel that named it, for example Sentinel 10.0.0.1:26379 named 10.0.0.5:6379 as the master of 'mymaster'.

Pasting a URL

A redis+sentinel:// URL fills the same fields: redis+sentinel://app:[email protected]:26379,10.0.0.2:26379/mymaster/2?sentinelPassword=s3cret lists the sentinels, then the master name, then (optionally) the database. Use rediss+sentinel:// for TLS, and add preferReplica=true (or readFrom=replica) to turn on reading from replicas. A comma-separated host list in an ordinary redis:// URL is kept whole as well.

Prefer replica for reads

With Prefer replica for reads on, a script made only of read-only commands (GET, HGETALL, SCAN, the key browser's reads, and so on) runs on a replica the sentinels report healthy. Anything that writes - and any script that mixes a write in, uses SELECT, or reads server-wide information for the dashboards and tools - runs on the master. When no replica is healthy, the master answers. Replicas are asynchronous, so a read can briefly return a value older than the master's.

Failovers

When the master changes while a connection is open, the next command fails with a dropped connection or a READONLY error from the demoted server. SQLly then asks the sentinels again - once per script - and moves the connection to the new master:

  • A read-only script re-runs the command that failed and carries on; you see nothing unusual.
  • A script that writes is never re-run for you. It stops with master changed, re-run and names the new master. The connection already points there, so running the script again works - but check first, because the write may have landed just before the old master went away and some commands earlier in the script may already have run.

Sentinel connections dial the sentinels, the master, and the replicas directly, so SSH tunnels, proxies and Kubernetes port-forwards are not available with Sentinel. Connections routed through a relay do not support Sentinel yet and say so when you test or connect. The Profiler and Pub/Sub viewer attach to the current master.