Hacker News Reader

Comment by koolba | Hacker News Reader

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?

View on HN

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?

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 don't believe the scripts are namespaced to a DB, so SWAPDB wouldn't effect their visibility.

Reply on news.ycombinator.com