SWAPDB Redis command
github.com
SWAPDB Redis command
1–10 of 20 posts
Re: SWAPDB Redis command
#2Looks cool. What would be the prototypical use cases for something like this?
I'd imagine something like this would already have been possible with a proxy (i.e. hot swap upstream without closing client connections).
Also, any idea how this handles clients that execute scripts via EVALSHA? If a client already loaded the script, wouldn't this break that expectation or does the client contract not allow caching that?
Re: SWAPDB Redis command
#3Looks cool. What would be the prototypical use cases for something like this? I'd imagine something like this would already have been possible with a proxy (i.e. hot swap upstream without closing client connections). Also, any idea how this handles clients that execute scripts via EVALSHA? If a client already loaded the script, wouldn't this break that expectation or does the client contract not allow caching that?
Hello koolba, I did not expect this commit to reach HN, but here we are... so: there are different use cases but distribution of read-only data to far places with an easy upgrade path for the data is one that comes to mind. Since this pattern is requested very often there are for sure other applications. About Lua, the scripts are atomic from the POV of Redis, so the swap happens before or after the script is executed: they should work as expected AFAIK, but thanks for hinting about that.
Re: SWAPDB Redis command
#4I'm blown away by how small the implementation is.
Re: SWAPDB Redis command
#5I'm blown away by how small the implementation is.
Yes, it's just a matter of swapping a few pointers and fixing inconsistencies with blocking clients, however this was conceptually possible thanks to the "lazyfree" work that is able to reclaim the old DB incrementally, and is a much larger implementation.
Re: SWAPDB Redis command
#6I'm blown away by how small the implementation is.
Yes, it's just a matter of swapping a few pointers and fixing inconsistencies with blocking clients, however this was conceptually possible thanks to the "lazyfree" work that is able to reclaim the old DB incrementally, and is a much larger implementation.
Yep, amazing 1:1 code to commit-message ratio. I love it.
Re: SWAPDB Redis command
#7Looks cool. What would be the prototypical use cases for something like this? I'd imagine something like this would already have been possible with a proxy (i.e. hot swap upstream without closing client connections). Also, any idea how this handles clients that execute scripts via EVALSHA? If a client already loaded the script, wouldn't this break that expectation or does the client contract not allow caching that?
I don't believe the scripts are namespaced to a DB, so SWAPDB wouldn't effect their visibility.
Re: SWAPDB Redis command
#8Interesting. I can think of a number of scenarios where this makes sense if you're using Redis for caching and you don't have a proxy in your architecture.
Does redis cluster only support one database? If that's still the case, then this is probably not available for the larger redis deployments.
Re: SWAPDB Redis command
#9Interesting. I can think of a number of scenarios where this makes sense if you're using Redis for caching and you don't have a proxy in your architecture. Does redis cluster only support one database? If that's still the case, then this is probably not available for the larger redis deployments.
Exactly, this is not available for Redis Cluster, even since the concept of atomically swapping cluster-wild would be more complex. When doing client-side sharding ala memcached for a plain caching scenario however, this can be applied, with the care needed to make sure that the application logic and consistency requirements, may tolerate that the DBs of the different masters are swapped potentially at different times.
Re: SWAPDB Redis command
#10Very interesting feature. Question: is it not standard protocol to add a test with a new feature like this?