CONFIG REWRITE doesn’t actually save your runtime configuration changes; it just applies them to the running Redis instance.
Let’s see CONFIG REWRITE in action. Imagine you’ve got a Redis instance running and you want to change the maxmemory setting. Normally, you’d do this with CONFIG SET maxmemory 1gb. But if Redis restarts, that change is gone. To make it persistent, you’d run CONFIG REWRITE.
Here’s how it looks in practice. You’re logged into your Redis instance via redis-cli:
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "0"
127.0.0.1:6379> CONFIG SET maxmemory 1gb
OK
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "1073741824"
127.0.0.1:6379> CONFIG REWRITE
OK
After CONFIG REWRITE, if you were to restart Redis, the maxmemory would still be 1gb. This is because CONFIG REWRITE reads the current configuration from the running Redis instance and writes it to the redis.conf file that Redis was started with. It’s essentially a way to synchronize the live configuration with the persistent configuration file.
The problem this solves is the ephemeral nature of runtime configuration changes. Without CONFIG REWRITE, any changes made via CONFIG SET are lost upon a Redis restart. This is crucial for maintaining desired Redis behavior across restarts, ensuring stability and predictable performance. Redis loads its configuration from the redis.conf file on startup. When you use CONFIG SET, you’re only modifying the in-memory configuration of the currently running process. CONFIG REWRITE bridges this gap by updating the source file.
Internally, when CONFIG REWRITE is executed, Redis performs the following:
- It identifies the configuration file that was used to start the current Redis instance.
- It iterates through all the configuration parameters that have been modified in the running instance (i.e., those that differ from the initial values loaded from the configuration file).
- For each modified parameter, it updates or adds the corresponding line in the
redis.conffile. For example, if you changedmaxmemoryfrom0to1gb, it would find themaxmemory 0line (or add it if it wasn’t present) and change it tomaxmemory 1gb. - It ensures that comments and other existing configuration lines are preserved as much as possible to avoid altering the overall structure of the file unnecessarily.
The exact levers you control are the configuration directives themselves. Any directive that can be changed at runtime using CONFIG SET can also be persisted using CONFIG REWRITE. This includes parameters like maxmemory, timeout, tcp-keepalive, slowlog-log-slower-than, and many others. The key is that CONFIG REWRITE operates on the currently running configuration.
A common point of confusion is that CONFIG REWRITE only writes the modified parameters back to the file. If a parameter was explicitly set in your redis.conf and then you changed it back to its default value using CONFIG SET, CONFIG REWRITE might remove that line from the redis.conf file, effectively reverting it to its default behavior on the next restart. This is usually desirable, as it cleans up the configuration file.
If CONFIG REWRITE fails, it’s typically because Redis doesn’t have write permissions to the directory where its redis.conf file resides, or the file itself is read-only.
The next error you’ll hit is likely a MISCONF error if you try to set a parameter that requires a restart, like changing the port without running CONFIG REWRITE and then restarting.