My application has extremely high performance requirements and the current Redis persistence options (RDB and AOF) is not fast enough. Since I can rebuild my data set anytime, I decided to turn off RDB and AOF and simply reconstruct my data set when I need to start the redis-server process. But, I can't run Redis without its data, or the client will receive a lot of "nil" replies.
To solve this problem I thought about running Redis on a different port, loading my data, and then setting the right port. But I noticed that "CONFIG SET port XXX" is not a valid config to change on-the-fly.
Would it be possible to add and remove a listening port to Redis? For instance, Redis could listen to 6379 and 6378 at the same time.
Is this too crazy?
This is not too crazy and I wanted to add this for a while now, albeit in a different form.
I was thinking about refactoring the bind/port/unixsocket/unixsocketperm into a new single bind. Depending on the arguments to this bind directive it will either bind to an IPv4 socket, IPv6 socket, or Unix socket. This will allow us to add and remove sockets to bind to at runtime, enabling the pattern you have in mind.
# IPv4 on any address
# IPv6 on localhost
# Unix socket
Don't have a timeline for this though ;-)
Of course we can synthesize such a bind statement if only old school bind/port/unixsocket/unixperm is provided in the configuration file, and provide backwards compatibility.
The unbind configuration directive will just be the reverse of bind, and mostly useful via CONFIG SET. Calling this should only be allowed if you are connected via a socket different from the one that is attempted to be unbound.
I understood your form. It would use the "bind" config to unify the config of the interfaces that Redis can listen to (the "unixsocket" config could be deprecated).
Btw, why restrict the "unbind" just to sockets that are different than the one the client is willing to unbind? I have implementend a system that could change the listening port and it worked great. But I only killed the old port after the new one was guaranteed to be working.
Let me know if I can be of any help on this implementation.
From the point of view of Redis a socket can be successfully listening, but tons of external factors (e.g. firewalls) can prevent clients from connecting. It would just be a fail safe to prevent people from making their Redis instance inaccessible.
I like this idea as well. There have been a few times I've wanted redis to be running but not accessible by outside clients until something is ready (data loaded, etc.)
@jzawodn What do you think of the proposal? Would it fit your use cases/do you have something else in mind?
@pietern I think your proposal would work well for what I had in mind.
Why not just tweak redis so that it replies with "-LOADING" until told otherwise? A well-written client will already deal gracefully with this error message. To switch it to active mode, you would just send a CONFIG SET that tells it that loading the data set has finished.
Of course, this would not be the default behavior -- you would be able to set this in the conf.