Fix: LOADING Redis is loading the dataset in memory

LOADING means Redis is up but not ready: after a restart it must read its entire dataset from the RDB snapshot or replay the AOF before it can serve commands, and until then it answers with this error. For a small dataset the window is seconds; for tens of gigabytes on slow disks it can be long minutes of an application acting as if the cache vanished. There are two things to handle: ride out or shrink the loading window, and find out why Redis restarted in the first place.

LOADING Redis is loading the dataset in memory

What this error means

Redis keeps its dataset in memory, and persistence files exist to rebuild that memory after a restart. During startup it reads the RDB file (a compact binary snapshot) or replays the AOF (a log of write commands, re-executed one by one), and while that runs the event loop answers commands with LOADING instead of serving partial data. This is correct behavior, not a fault: the alternative would be answering reads from an incomplete dataset. The error becomes an incident when the restart was unplanned, the dataset is large, or nothing else can serve traffic while the node loads.

Common causes

• An unplanned restart: the OOM killer, a crash, a host reboot, or a managed-service failover or maintenance event.
• A planned restart (deploy, config change) on a dataset large enough that loading takes real time.
• AOF replay after a crash, which is much slower than RDB loading because every write is re-executed.
• Slow storage under the persistence file, stretching a load that would be quick on local SSD.
• No replica to serve during the window, so one node’s startup becomes application-wide cache loss.

How to fix it

STABILIZE first. Confirm the load is progressing and get its ETA, so you know whether you are waiting ninety seconds or an hour. Do not restart Redis again, which starts the load over from zero.

redis-cli INFO persistence | grep -E 'loading:|loading_loaded_perc|loading_eta_seconds'

1. If a replica has the dataset and is current, fail over so it serves traffic while the restarted node finishes loading. With Sentinel:

redis-cli -h <sentinel-host> -p 26379 SENTINEL failover mymaster

2. Make the application degrade gracefully meanwhile: treat LOADING like a cache miss with backoff (fall through to the database, rate-limited) rather than an exception that fails requests.

3. DIAGNOSE why Redis restarted, because the loading screen is the symptom. Read the tail of the previous run in the Redis log and check the kernel log for an OOM kill.

grep -iE 'signal|crash|oom|Ready to accept' /var/log/redis/redis-server.log | tail -10
dmesg -T | grep -i 'killed process' | tail -5
journalctl -u redis-server --since "2 hours ago" | tail -30

An OOM kill means the real incident is memory sizing: set maxmemory below what the host can actually give Redis and pick an eviction policy, so the kernel never has to choose for you.

redis-cli CONFIG SET maxmemory 6gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru

4. FIX the loading time itself if it is the pain. If crash recovery replays a huge AOF, enable the RDB preamble so most of the file loads at snapshot speed:

redis-cli CONFIG GET aof-use-rdb-preamble
redis-cli CONFIG SET aof-use-rdb-preamble yes

Put the persistence files on fast local SSD rather than network storage, and if the dataset has grown into tens of gigabytes, consider splitting it across shards so no single node’s restart takes long.

5. Verify readiness before returning traffic to the node.

redis-cli PING

A PONG instead of a LOADING error means the dataset is fully loaded.

How to prevent it

• Run at least one replica with failover (Sentinel, cluster, or a managed multi-AZ tier), so a restarting node never equals an unavailable cache.
• Cap memory with maxmemory and an eviction policy so the OOM killer stops being the thing that restarts Redis.
• Keep persistence on fast local disks and use the AOF RDB preamble to keep recovery quick.
• Alert on Redis restarts and on the LOADING error rate in application logs, so unplanned restarts are investigated, not just survived.
• Rehearse restarts in staging with a production-sized dataset, so the loading window is a known number before it happens at 3 a.m.
• Handle LOADING explicitly in application cache clients as a temporary condition with fallback.

When to call a senior engineer

Call for help when Redis keeps restarting and each recovery window hurts more as the dataset grows, when failover does not kick in and one node’s startup takes the application down, or when nobody can say whether memory sizing, persistence strategy, and topology still fit the workload. Erzon engineers can find what is killing the process, redesign persistence and replication so restarts are invisible to users, and size the deployment so loading time stops being an outage class of its own.