SWAPDB Redis command | Hacker News Reader

SWAPDB Redis command

github.com

121 pointsopenmaze19 comments

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?

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.

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?

I don't believe the scripts are namespaced to a DB, so SWAPDB wouldn't effect their visibility.

In a previous job, we'd receive weekly updates of data from a vendor that would need to be imported into the database. There were a few occasions where the update file had errors which would break the application where this data was used. Features like this mean that one can very quickly roll back to previous known good data, and also troubleshoot a problem by comparing results to what they were last week/month/etc.

I'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.

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

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.

ahh got it! thanks :)

Amazing feature. Amazing product. Thanks antirez.

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?

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.

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?

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.

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.

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?

Nice !

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

Reply on news.ycombinator.com