WIUNIX ACADEMY
Set up Redis Sentinel high availability on Ubuntu and Debian
Page 2 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
Stop the new instances and preserve their package defaults
Fresh tutorial nodes only; never stop an unrelated production instance. The protected backup retains path structure. Both configuration files must be present. Keep the backup outside Git and public storage.
sudo systemctl stop redis-sentinel redis-server
sudo bash -eu <<'BACKUP'
umask 077
test -f /etc/redis/redis.conf
test -f /etc/redis/sentinel.conf
install -d -m 0700 /root/academy-backups
backup=$(mktemp -d /root/academy-backups/redis-defaults-XXXXXXXX)
tar -C / -cpf "$backup/etc-redis.tar" etc/redis
tar -tf "$backup/etc-redis.tar" >/dev/null
tar -C / -df "$backup/etc-redis.tar"
printf 'Defaults retained: %s\n' "$backup"
BACKUP
Both dedicated services are stopped and the original configuration archive is readable and matches its source.
LET’S BUILD
Install host-specific certificates without moving the CA key
On each node, an existing approved PKI must already have placed ca.pem, node-fullchain.pem and node-key.pem in the protected input directory. Each node has a DIFFERENT key/certificate with its own private-IP SAN, serverAuth AND clientAuth EKUs, current validity and a trusted chain. Do not copy the CA private key or reuse one node key on three hosts. Provide an independently issued client certificate to the application/admin host. Redis mTLS checks trust in the configured CA, not an application username mapping; ACL authentication is still required. Native replication/Sentinel CA validation must not be described as hostname verification. Use a CA dedicated to this Redis deployment, strict private routing and source ACLs; clients that require endpoint-name validation must explicitly support/check it.
(
set -euo pipefail
sudo install -d -o root -g redis -m 0750 /etc/redis/tls
sudo install -o root -g redis -m 0640 /root/academy-pki/ca.pem /etc/redis/tls/ca.pem
sudo install -o root -g redis -m 0640 /root/academy-pki/node-fullchain.pem /etc/redis/tls/node.pem
sudo install -o root -g redis -m 0640 /root/academy-pki/node-key.pem /etc/redis/tls/node.key
sudo openssl verify -CAfile /etc/redis/tls/ca.pem -purpose sslserver /etc/redis/tls/node.pem
sudo openssl verify -CAfile /etc/redis/tls/ca.pem -purpose sslclient /etc/redis/tls/node.pem
sudo openssl x509 -in /etc/redis/tls/node.pem -noout -dates -ext subjectAltName
sudo openssl x509 -in /etc/redis/tls/node.pem -checkend 604800 -noout
sudo openssl x509 -in /etc/redis/tls/node.pem -pubkey -noout | openssl sha256
sudo openssl pkey -in /etc/redis/tls/node.key -pubout | openssl sha256
sudo -u redis test -r /etc/redis/tls/node.key
)
Both purposes validate, IP SAN is correct, key/public-key hashes agree and redis can read the private key.
Six separate credentials; no secrets in command arguments
Create six independent 64-hex-character secrets in your existing secret manager: ADMIN for protected maintenance; APP for academy:* GET/SET/WAIT plus role/health checks only; REPL for replication; CONTROL for Sentinel→Redis control; PEER for Sentinel→Sentinel administration; DISCOVERY for read-only topology lookup. Use the SAME role’s secret on all three nodes, but never reuse secrets between roles. All REPLACE_* tokens below are placeholders and must be replaced inside the protected editor, not pasted into a shell command. Never enable shell tracing, record the secret-editing terminal, use CLI password arguments or publish ACL/config dumps. Redis needs the outbound REPL/CONTROL/PEER passwords in protected configuration; hashing inbound ACL passwords alone does not remove those secrets.
LET’S BUILD
Open the Redis ACL file
On each node. The next panel is FILE CONTENT, not shell. Replace all four secrets before saving. The default user is disabled. Applications receive no Pub/Sub access, particularly not the reserved Sentinel hello channel. ADMIN is privileged but initially has no channel grants; CONTROL alone gets the reserved channel.
sudo install -o root -g redis -m 0640 /dev/null /etc/redis/users.acl
sudo nano /etc/redis/users.acl
The protected file is ready for the following ACL content.
Redis ACL contents
File content on A/B/C. REPL can stream the dataset without ordinary key commands; protect that credential as data access. CONTROL can change topology and rewrite configuration, so it is not an application identity. Do not give APP or REPL broad channel grants.
user default off
user admin on >REPLACE_ADMIN_64_HEX ~* resetchannels +@all
user app on >REPLACE_APP_64_HEX ~academy:* resetchannels -@all +ping +role +get +set +wait
user repl on >REPLACE_REPL_64_HEX resetchannels -@all +ping +replconf +psync
user control on >REPLACE_CONTROL_64_HEX resetchannels &__sentinel__:hello -@all +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill
LET’S BUILD
Edit the writable Redis configuration
On A/B/C, replace the packaged file with the next dedicated-node configuration. A uses 10.20.0.10; on B replace BOTH local bind and announce IP with 10.20.0.11; on C use 10.20.0.12. Use the same REPL secret as its ACL on every node, including A, so a former primary can rejoin. Config must remain writable for Sentinel CONFIG REWRITE; preserve the package backup.
sudo nano /etc/redis/redis.conf
The correct local IP and shared replication credential are prepared.
Redis file contents; size memory for the workload
This 256 MB dataset limit is only a small lab budget, not a capacity recommendation. Leave additional RAM for process overhead, client buffers, replication and fork/copy-on-write during persistence. noeviction rejects writes when full. min-replicas 1 bounds some isolated-primary writes after lag 10 s; it does not fence instantly or guarantee zero loss. Three DATA nodes let a promoted node still have one replica after one host failure; with only two data nodes the promoted primary would reject writes until the other rejoins under this policy.
bind 127.0.0.1 10.20.0.10
protected-mode yes
port 0
tls-port 6379
tls-cert-file /etc/redis/tls/node.pem
tls-key-file /etc/redis/tls/node.key
tls-ca-cert-file /etc/redis/tls/ca.pem
tls-auth-clients yes
tls-protocols "TLSv1.2 TLSv1.3"
tls-replication yes
daemonize no
supervised systemd
pidfile /run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis
dbfilename dump.rdb
save 900 1
appendonly yes
appendfsync everysec
maxmemory 256mb
maxmemory-policy noeviction
aclfile /etc/redis/users.acl
masteruser repl
masterauth REPLACE_REPL_64_HEX
replica-announce-ip 10.20.0.10
replica-announce-port 6379
replica-read-only yes
replica-serve-stale-data no
min-replicas-to-write 1
min-replicas-max-lag 10
Append the initial upstream on B and C only
On B/C ONLY append this line to the preceding file through the same editor. A must not have this line at initial bootstrap. After failover, let Sentinel own the actual role and rewritten address; do not repeatedly deploy this bootstrap file and revert the topology.
replicaof 10.20.0.10 6379