Part 9 · 1 chapters · ~8 min
Operating Redis and Valkey
Monitoring (INFO sections, latency, memory, hit ratio, evictions, connected clients), sizing and headroom for forks, security (ACLs, TLS, protected mode, never exposed to the internet), upgrades, managed services (ElastiCache, MemoryDB, Upstash), Valkey compatibility, and the incidents that happen.
12
Running it
code
INFO stats # keyspace_hits / (hits + misses) = hit ratio; evicted_keys; rejected_connections INFO clients # connected_clients, blocked_clients INFO replication ; INFO persistence ; INFO memory ACL SETUSER app on >s3cret ~cache:* ~rl:* +@read +@write -@dangerous # least privilege per app CLIENT LIST # who is connected, idle times, commands
| incident | cause | prevention |
|---|---|---|
| latency spikes every few minutes | fork for RDB/AOF rewrite on a large dataset | headroom, persistence on replicas only, smaller instances |
| sudden total stall | KEYS * or a huge DEL in production | rename or ACL-deny dangerous commands; SCAN and UNLINK |
| OOM errors on writes | noeviction with a cache workload, or keys without TTLs | TTLs everywhere; right policy per instance |
| data loss after failover | asynchronous replication | WAIT for critical writes; a database for the source of truth |
| compromised server | Redis exposed to the internet without auth | private networks, ACLs, TLS, protected mode |
Valkey (Linux Foundation fork of Redis 7.2) is protocol-compatible and adds its own improvements, including multi-threaded IO work; AWS, Google Cloud and others offer it as a managed service. Clients for Redis work with it unchanged.