
SWAPDB Redis command - openmaze
https://github.com/antirez/redis/commit/c7a4e694ad3689d934897b0d2c37144d7b2d0b97
======
koolba
Looks 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?

~~~
antirez
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.

~~~
koolba
Cool, thanks for the reply and I've said this a number of times before on HN,
but I'll say it again, I really love working with Redis!

Any plans to tie this into clustering/sentinel? Say if there's a cluster of
redis servers, to have all of them switch over to a new DB in tandem?

------
Beltiras
I'm blown away by how small the implementation is.

~~~
antirez
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.

~~~
alpb
Yep, amazing 1:1 code to commit-message ratio. I love it.

------
jtmarmon
Very interesting feature. Question: is it not standard protocol to add a test
with a new feature like this?

~~~
antirez
Yep it's standard, just instead of going into the same commit went into my A4
paper "TODO before 4.0 RC1", since I was not sure about the users welcoming
the feature.

~~~
jtmarmon
ahh got it! thanks :)

------
pellej_s
Amazing feature. Amazing product. Thanks antirez.

------
ixtli
I thought that, with the introduction of redis cluster in 3.x, they were
moving away from multiple logical "dbs" that had indicies. Are they going to
continue to multiple databases in 4?

~~~
antirez
Hello, it's basically both... Cluster: no multiple DBs, since IMHO they don't
fit the idea of a distributed DB a lot. Single instance: even more support for
multiple DBs in order to create complex caching patterns. This may look
strange but I think that Redis Cluster use cases don't need the complexity of
multiple DBs, while Redis as a single instance (even if combined in client-
side multi master shards or whatever) can benefit of multiple DBs and things
like SWAPDB in order to allow the developer to use Redis as a building block.

~~~
ixtli
Thanks for your response, sorry it took me so long to respond! Personally the
cluster pattern is more intuitive for me and the problems I solve. I had
thought that there was a sense that using multiple dbs in one redis instances
was a bit of an anti-pattern. Are there any docs on some examples of the
building block configurations you're talking about?

------
neovintage
Interesting. 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.

~~~
antirez
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.

------
cbsmith
Couldn't one achieve the same thing simply by prefixing your DB keys with a
blue/green bit and just atomically swap out which prefix should be used for
reads?

------
ing33k
Nice !

would have saved us some time if this feature was there in an earlier release
.

