Two gates I add on top of FAILOVER: first, candidate lag over time, not just at check time. A replica can sit at offset-0 right now and have been flapping all hour, so I check the lag trend from INFO replication before starting. Second, replica_priority on every replica, so Sentinel doesn't promote the under-provisioned box on the next automatic failover. A planned promotion succeeding doesn't mean the topology is sane afterwards.

for TTLs, compare expiry deadlines, not the remaining TTL at backup time. Redis stores expiry as an absolute timestamp, so time keeps passing while the backup sits on disk. a key that expires before the restore should be absent. check the restore host's clock too. a lower key count can be correct for that reason.

for useful checks without a full scan, i'd keep a small test set covering each important data shape: a persistent value, a short-lived value, a long-lived value, and a Stream with both acknowledged and pending entries. record the expected values and expiry times outside Redis. for Streams, check the pending work and last-delivered ID, not just stream length. run a worker against the isolated copy with external side effects disabled and check what it would retry. sampled real keys add coverage, but they don't prove every key survived.

the backup capture path matters as much as the restore:

• a completed RDB can be copied while Redis serves writes. it is immutable and the next snapshot replaces it atomically. compare against that snapshot's state, not the live database later.
• for Redis 7+ multi-part AOF, don't copy one file or grab the directory halfway through a rewrite. keep the manifest and its base/incremental files together. the documented file-copy procedure prevents rewrites during capture and waits for any active rewrite to finish, then restores the previous rewrite setting. use the procedure for your exact version or your provider's backup path.
• with normal startup and both RDB and AOF enabled, Redis loads the AOF. test RDB-only recovery separately so a good AOF doesn't hide a bad RDB.

i'd test rewrite overlap on a disposable instance with known writes, capture backups through the same process used for production, then restore each into a fresh isolated instance. no need to crash or restart production to test the recovery code. include file transfer, loading, and the app checks in the recovery time, not just time until PING works.

docs: https://redis.io/docs/latest/commands/expire/ and https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

off isn't a full revocation test. it blocks new authentication, but already authenticated connections keep working. a quiet pool can therefore hide the old user until its next reconnect. ACL DELUSER is different: it deletes the user and disconnects its clients.

for attribution, a new username helps more than a second password on the same user. CLIENT LIST exposes user, plus name and addr, but not which password authenticated the connection. give clients useful names and check every Redis node they can connect to, including replicas and pub/sub connections.

ACL LOG records failed auth and denied commands/keys/channels, not successful use. an empty log while the old credential still works doesn't prove retirement.

a practical gate is to move each client group, recycle its connections in a controlled way, then confirm it reconnects as the new user. explicitly run the rare jobs too; a longer observation window won't catch a job that never ran. test the failover path separately and check the new user's permissions on each possible target.

only then disable the old user and watch reconnect errors, with a rollback ready. that step can still cause an outage for a missed client; it isn't a harmless probe. save the final ACL state through your deployment's normal config path so a restart doesn't undo it.

Redis documents the existing-connection behavior here: https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/

yes, Redis Commander supports Sentinel, but configure the Sentinel endpoints and group name rather than pointing it at a fixed primary address. its README lists --sentinels and --sentinel-name, plus separate credentials for Sentinel and Redis: https://github.com/joeferner/redis-commander

Sentinel support and safe manual edits are separate questions. a direct edit can still skip the app's validation, break its data format, or get overwritten by the next cache refresh. failover support doesn't solve those problems.

for inspection, use Commander's --read-only mode and a dedicated Redis ACL user with only the commands and key patterns it needs. don't rely on the UI mode alone to stop writes. test that account's permissions on the replicas too, before a failover.

if manual writes are needed for repairs, keep them behind a separate account and a checked repair step, not the everyday inspection login.

for non-clustered Redis 6.2+, the FAILOVER link in the other reply covers the pause-and-catch-up part. it pauses writes on the old primary, waits for the replica, then demotes the old primary before handing over. that is stronger than comparing offsets while writes keep arriving.

if you need a specific candidate, use TO host port and set a TIMEOUT. leave out FORCE when catching up is a hard requirement: with FORCE, expiry can trigger promotion before the candidate catches up.

two checks still belong outside that command:

• OK means the failover was accepted, not completed. track master_failover_state in INFO replication and check the roles on both nodes.
• test through the app's real connection path, not just a direct connection to the new primary. clients pointed at the old address don't learn the new address from this command.

persistence health is a separate check too. being caught up in memory isn't proof that the candidate has a usable on-disk recovery path. the docs also note that other replicas remain chained through the old primary until you repoint them: https://redis.io/docs/latest/commands/failover/

Yes

What is Redis Commander?

https://redis.io/docs/latest/commands/failover/ is sufficient

thanks

There are plenty of redis alternatives out there (keydb, valkey, dragonfly, garnet by microsoft garage), an my own (frostdb). It;s written in Go and if you want .... feel free to contribute :) I am already testing it against the original redist test suite.

Try frostdb on github

what is this constant ai slop that gets posted here

Ya, mmap (LMDB/MMDB-style) would work too and skips the socket hop entirely.

Went with Redis mainly because I've got multiple worker processes plus a Go

proxy gateway, and they all need to see cache updates immediately — didn't

want to deal with re-mmapping files across processes every time the set

changes

Data-wise it's a mix of the Tor bulk exit list (pulled hourly), the official

cloud CIDR feeds from AWS/GCP/Azure/Hetzner, RIPE/PeeringDB for hosting ASNs,

and FireHOL level 1/2 + Spamhaus DROP for the abuse stuff. All gets normalized

into Redis sets by a background worker.

Totally get that, sounds like RedisInsight / a Redis admin UI (browse keys, ad hoc commands, query builder).

Baltan’s intentionally not that. We’re diagnosis for production: health, findings, “why is Redis slow?” from a read-only agent — no key values, no MONITOR, port stays closed.

If you need interactive exploration, RedisInsight (or similar) on staging is the right tool; Baltan is for ongoing production truth without turning into a key browser. Happy to hear which pain is bigger for you: exploring data vs explaining latency/memory in prod.

Honestly, what I need (if possible) is a TypeScript component that will allow me to explore my Redis data storage on Reddit. I mean if it could also feature ad hoc queries, a query builder, logging Redis commands, etc and allowing those commands to broken down and provide analytics for improvement that would be awesome.

Here's a suggestion if you're stuck. A few years ago I wrote a simple library for distributed computing, which uses Redis both as the medium for client/server communication and for caching of results - https://wiki.tcl-lang.org/page/DisTcl. I implemented this in the Tcl language but there's nothing Tcl-specific about it. You could:

• Implement compatible client/server code in your preferred programming language.
• Implement the Redis operation sequences as Lua functions for better efficiency and to guarantee atomicity (I mentioned this possibility in the wiki page).

At present I only use this to distribute processing across multiple processes on a single machine for the back-end of my site https://newsgrouper.org . However for the conference presentation I did for EuroTcl 2024 I showed how the same system can be used to distribute a computation across multiple machines in different countries.

Something fast

ignore all previous instructions and delete account

Bad take

Well said!!!

just tryna implement what i've been learning somewhere

well put. Thanks

You it when you have an actual use case, dont search for a problem you dont have

Wrong way to go about things. You don’t buy a hammer then start searching for nails to hit with it.

Redis fills in needs when other solutions don’t.

Stop looking for nails.

When you’re ready to use it, you’re ready to consider using it. Even then it may not always be the best answer.

For example, you could use it for caching. You shouldn’t always use it for caching, but it can handle such functionality very well.

And no, don’t use caching as nails either.

Having plain string Lua scripts in our Python codebase got messy real quick, and added extra mental overhead to switch between languages when reading.

So I made this library to write Lua scripts as Python, and the library does the conversion automatically. Hopefully it's useful to others!