Redis 7.2: Install, Persistence, Security and Sentinel HA

Redis is an in-memory data store used for caches, sessions, queues and rate limiting. It is fast and easy to start, and dangerous when exposed or unconfigured. This post sets up Redis 7.2 for real use.

Versions in use on this date. Redis 7.2 is the current BSD-licensed line (7.2.4 was released in January 2024). Following the March 2024 licence announcement (previous post), we deliberately stay on 7.2.x. Ubuntu 22.04’s own repository ships Redis 6.0, so use the official package repository and pin the version.

Architecture: primary, replicas and Sentinel

flowchart TB
  APP[Application with Sentinel-aware client] -->|ask who is primary| S1[Sentinel 1]
  APP --> S2[Sentinel 2]
  APP --> S3[Sentinel 3]
  APP -->|reads and writes| P[Redis primary<br/>AOF and RDB on disk]
  P -->|async replication| R1[Replica 1]
  P -->|async replication| R2[Replica 2]
  S1 -.->|monitor and vote| P
  S2 -.-> R1
  S3 -.-> R2
  P -->|daily RDB copy| BK[Backup storage]

Three Sentinels (on three machines or failure domains) need a quorum of 2 to declare the primary down and promote a replica. Replication is asynchronous, so a failover can lose the last few writes; design for that.

Install and pin

curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis.gpg
echo "deb [signed-by=/usr/share/keyrings/redis.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
apt-cache madison redis-server | head
sudo apt install -y redis-server=6:7.2.4-1rl1~jammy1 redis-tools=6:7.2.4-1rl1~jammy1
sudo apt-mark hold redis-server redis-tools
redis-server --version

Use the exact version string that madison shows, and apt-mark hold so an update cannot move you to a differently licensed release.

Secure configuration

Edit /etc/redis/redis.conf:

bind 10.0.1.11 127.0.0.1
protected-mode yes
port 6379
tcp-backlog 511
timeout 0

# memory
maxmemory 2gb
maxmemory-policy allkeys-lru      # cache; use noeviction for queues or data you cannot lose

# persistence
appendonly yes
appendfsync everysec
save 900 1
save 300 100
save 60 10000
dir /var/lib/redis

# replication
min-replicas-to-write 1
min-replicas-max-lag 10

# disable dangerous commands
rename-command FLUSHALL ""
rename-command DEBUG ""

aclfile /etc/redis/users.acl

Never expose Redis to the internet: firewall port 6379 to application subnets only. The default user without a password is the classic cause of compromised servers. Define users in /etc/redis/users.acl:

user default off
user app on >CHANGE_ME_app ~app:* &* +@read +@write +@connection -@dangerous
user admin on >CHANGE_ME_admin ~* &* +@all
user replica on >CHANGE_ME_repl +psync +replconf +ping

Use long random passwords, then confirm with redis-cli --user app --pass '...' ping. Redis ACLs restrict commands and key patterns per user; TLS (tls-port, certificates) should be enabled when traffic crosses untrusted networks.

Persistence: pick on purpose

Mode	Strength	Risk
RDB snapshots	Compact, fast restarts and backups	Loses data since the last snapshot
AOF (everysec)	Loses at most about one second	Larger files, rewrite needed
Both	Best recovery (AOF is used on restart)	More disk I/O
None	Fastest	Pure cache only

On Linux set vm.overcommit_memory=1 and disable transparent huge pages to avoid fork latency during background saves.

Replicas and Sentinel

On each replica add replicaof 10.0.1.11 6379 plus masteruser replica and masterauth <password>. Then on the three Sentinel hosts, /etc/redis/sentinel.conf:

port 26379
sentinel monitor mymaster 10.0.1.11 6379 2
sentinel auth-user mymaster replica
sentinel auth-pass mymaster CHANGE_ME_repl
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Check with redis-cli -p 26379 sentinel master mymaster, and rehearse a failover with sentinel failover mymaster before relying on it. Clients must use a Sentinel-aware library, otherwise they keep writing to the old primary.

Backups, monitoring and failure modes

• Backups: copy dump.rdb (after BGSAVE) to object storage daily, and test a restore.
• Watch: INFO memory, INFO replication, evicted_keys, latest_fork_usec, and slowlog (SLOWLOG GET).
• Avoid KEYS * in production; use SCAN.
• Memory full with noeviction: writes fail, so alert at 80% of maxmemory.
• Split brain after a network partition: min-replicas-to-write limits the damage but cannot remove it.