WIUNIX ACADEMY
Set up Redis Sentinel high availability on Ubuntu and Debian
Page 7 of 7. Review the earlier steps and prerequisites before continuing.
YOUR SYSTEM. YOUR STEPS.
Where are you working?
Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.
USE YOUR OWN VALUES
Configure this tutorial
Set the example values for your environment; related explanations and copy panels update together. Never enter passwords, private keys or tokens. Values stay in this tab and are not sent to the server or share links. Check actual DNS, certificates and network policy before running commands.
Different IP addresses, domains or ports? Open the settings below, change the values and select “Apply to tutorial”, then copy the updated commands.
Set values for my environment5 editable values
LET’S BUILD
Verify old data, then a new replicated write
GET must still be before-failover. SET must be OK and WAIT 1 must return 1, otherwise stop. Read the new value on the remaining replica using its local APP login as well; checking only the primary is insufficient. A different lost marker is a failed recovery result, not permission to overwrite data.
ROLE
GET academy:probe
SET academy:probe after-failover
WAIT 1 5000
GET academy:probe
QUIT
Check the role, exact values and required responses described above; stop on any unexpected result.
LET’S BUILD
Return the old node without restoring the old topology
On A ONLY keep application access fenced. Start its retained config/data; Sentinel should reconfigure it as a replica of the elected primary. Do not add replicaof no one, copy the bootstrap file or expose it to writers during convergence. Sentinel may replace a divergent former-primary dataset during resync; this rehearsal has no independent writes on fenced A. A real divergent node needs preserved offline evidence and a recovery decision first.
sudo systemctl start redis-server
sudo systemctl status redis-server --no-pager
sudo tail -n 50 /var/log/redis/redis-sentinel.log
A starts and is reconfigured as a replica; client access remains fenced until role/data checks pass.
LET’S BUILD
Confirm rejoin on A and topology on every voter
On A use the Redis ADMIN login: require replica role, new master address, link up, no full sync in progress and successful persistence. APP GET on A must equal after-failover; APP SET must be READONLY. Repeat all-voter topology/quorum checks. Keep the elected primary rather than forcing an immediate failback. Only then update approved client routing and restore the intended private access policy.
ROLE
INFO replication
INFO persistence
QUIT
Check the role, exact values and required responses described above; stop on any unexpected result.
LET’S BUILD
Data-preserving reversal for this dedicated lab
Before retiring the LAB, stop application traffic through its owning control, fence all data endpoints and retain checked backups plus successful isolated restore evidence. Then run on A/B/C to disable automatic voting and both dedicated services. This is a maintenance outage, not a way to keep HA while removing Sentinel. Files, AOF/RDB and permissions remain intact. Never purge packages, flush data or blindly restore bootstrap roles. Re-enabling requires an explicit current-primary decision, consistent roles and fresh all-voter/data checks before opening clients.
sudo systemctl disable --now redis-sentinel
sudo systemctl disable --now redis-server
sudo systemctl is-enabled redis-sentinel redis-server
sudo ss -lntp
Both dedicated services are disabled/inactive (nonzero is-enabled is expected); retained data/configuration remain available for recovery.
Diagnose the consequence before changing the topology
Use each diagnostic on its stated host/session. Logs can contain private topology; share only reviewed redacted extracts. An expected authorization refusal is different from a failed quorum or missing data.
Service will not start
Read the actual file log and unit result. A bad ACL token, wrong local bind IP, missing key or permission failure needs correction in the earlier protected editor. Do not launch a second daemon against the same data directory or disable TLS to make it start.
sudo systemctl status redis-server redis-sentinel --no-pager
sudo journalctl -u redis-server -u redis-sentinel -n 60 --no-pager
sudo tail -n 60 /var/log/redis/redis-server.log /var/log/redis/redis-sentinel.log
ip -br address
sudo -u redis test -r /etc/redis/tls/node.key
sudo -u redis test -w /etc/redis/sentinel.confNo quorum or replicas remain disconnected
Use the earlier authenticated Sentinel session to inspect MASTER/REPLICAS/SENTINELS and CKQUORUM. Missing peers can be wrong announce IPs, blocked 26379 or PEER credentials; missing replicas can be blocked 6379, REPL/CONTROL ACLs or TLS. A voter needs writable config AND directory. Keep reserved-channel rights limited to CONTROL.
sudo ss -lntp
sudo tail -n 80 /var/log/redis/redis-sentinel.log
sudo -u redis test -w /etc/redis
sudo -u redis test -w /etc/redis/sentinel.confNOREPLICAS, READONLY or missing marker
NOREPLICAS is the minimum-replica policy rejecting unsafe writes: inspect the current primary replication state, rather than setting the limit to zero. READONLY at the original primary often means election succeeded and the client has a stale endpoint. Missing marker is a failed data check: fence traffic and preserve nodes for recovery. Use the ADMIN login then this CLI diagnostic session.
ROLE
INFO replication
INFO persistence
QUITTLS or certificate renewal failure
On the affected host check expiry, trust and key readability using the earlier PKI panel. For this local certificate verification replace the IP with the node’s actual assigned IP. A successful CA check alone is not endpoint-name verification. Renew certificates with overlap and recheck all TLS paths; no --insecure workaround. Never paste private keys or secret-bearing configs into a ticket.
sudo openssl verify -CAfile /etc/redis/tls/ca.pem -purpose sslserver -verify_ip 10.20.0.10 /etc/redis/tls/node.pem
sudo openssl x509 -in /etc/redis/tls/node.pem -checkend 604800 -noout
sudo -u redis test -r /etc/redis/tls/node.keyDisk or AOF errors
On the affected node inspect capacity, inodes and actual persistence status via the earlier ADMIN session. AOF rewrite needs temporary disk/RAM headroom. Stop adding traffic when persistence fails; do not delete AOF segments or run redis-check-aof --fix against the only copy. Preserve files and restore a checked backup in isolation before a repair decision.
df -h /var/lib/redis /var/log/redis
df -i /var/lib/redis
sudo tail -n 80 /var/log/redis/redis-server.logOperate the recovery path, not just the election
Monitor replication lag/offset, replica count, quorum, failovers, persistence errors, disk headroom, certificate expiry and client reconnect/error rates. Alert before the minimum-replica policy blocks writes. Next rehearse the actual application library, one failure-domain outage and an isolated backup restore with representative data. Choose a different datastore/consensus design if acknowledged-write loss is unacceptable; do not describe Sentinel as zero-RPO.
GO TO THE SOURCE
Official references
Each environment states how it was reviewed. A documentation review does not claim a hands-on test of every version.
- Redis upstream security support
- Redis Open Source release notes
- Redis licenses
- Sentinel deployment, quorum and authentication
- Replication and asynchronous limits
- TLS for clients, replication and Sentinel
- Redis ACL reference
- Persistence and backup
- Sentinel-aware client requirements
- WAIT command
- Ubuntu 26.10 Redis package
- Ubuntu 26.04 Redis package
- Ubuntu 24.04 Redis package
- Debian 13 Redis package
- Debian 12 Redis package
- Debian Redis security tracker
- Ubuntu package security coverage
KEEP LEARNING