The problem/use-case that the feature addresses
Redis Sentinel can be hard to use, since every programming language and framework is dependant on the more or less well implemented version of Redis Sentinel. In the long run, it would be better a great improvement to get rid of the whole Redis Sentinel stack and have a working multi-master replication.
Description of the feature
This way, no promotion of a node in case of failure is necessary, clients can simply send their write requests to any server, etc. In fact, KeyDB already ships with some sort of multi-master replication, though its not working perfectly. My alert system sends me a bunch of emails to my private email albert1.cornelius+github@gmail.com everytime a Sentinel thinks, that the master is down.
Alternatives you've considered
Well... switching to KeyDB?
Is there any info on the roadmap?
Comment From: oranagra
I don't think this topic is on our roadmap.
i'm not keen on the details of KeyDB and your use case, but AFAIK it poses some serious complications, not just the fact data needs to be propagated. e.g. how are conflicts resolved? what happens when a propagated command that succeeded on the source, fails on the destination since the base data on the destination is different...
Comment From: hwware
multi-master means multiply nodes will accept write operations, and it will be totally different from current Redis design, and data inconsistence happens very easily. You could try to use the redis cluster, but in this situation, the promot action still happens when one of the master node down.
Comment From: eduardobr
@gappymate, out of curiosity, in your case what's the main reason for having multi-master? Is it high availability of writing points? Or you need it for something else, like scaling writes? I'm asking because it seems it's not to scale, considering that a write to one master is replicated to another and then the total amount of writes per master is the same as if you had a single master. So is the reason the high-availability + guaranteed durability? (No loss of writes during failovers)
If yes, I think it's a great point, and in the correct platform (like Kubernetes) this seems to be doable to adjust Redis for (changing it's implementation of course). But I would like to understand your reason for multiple masters before going further.
Comment From: zuiderkwast
I agree Sentinel is not so nice. It's better to use Redis Cluster IMO. With Redis Cluster, the Redis nodes themselves know which node is the master for each key. If a failover has happened or if some keys have been moved from one master to another master, the user will get a MOVED redirect. Redis Cluster capable clients normally handle this well. They follow the redirect and send the command to the right node.