11–20 of 20 posts
Very interesting feature. Question: is it not standard protocol to add a test with a new feature like this?
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.
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 execute…
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?
would have saved us some time if this feature was there in an earlier release .
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?
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?
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)…