|
|
|
|
|
|
by lucian1900
4487 days ago
|
|
|
> Sentinel is just a Redis-aware consensus driven failover service But its consensus algorithm is broken to the point where it will lose half of your recent data any time an election happens (much like MongoDB). > Redis Cluster has very specific use cases. What are those? It's neither CP nor AP apparently. What guarantees does it make? |
|
|
lucian1900, it sounds like you are confused about consensus about failover, and consensus about data.
Redis Sentinel uses a form of consensus in order to have a consistent view of the configuration, however this does not mean the store it will failover turns into a CP system that features strong consistency.
So if you consider Sentinel + Redis as an unique system, Sentinel guarantees that every given partition of Sentinels agree about the configuration (as a general case when all the partitions heal, all Sentinels will agree). It also guarantees to failover only in the majority side.
However when there is a partition and there are clients with a master that is in the minority, Sentinel does not make Redis automatically consistent, since Redis is asynchronously replicated.
In order to put a bound to the desynchronization possible (and the amount of writes you can lose in this scenario), you can configure Redis so that if it is not connected to N slaves receiving acks for M milliseconds, it stops accepting writes.
So what you do is to asynchronously sense the split and bound the write loss.
Example: you have three nodes, each run a Sentinel and a Redis instance. If your master gets partitioned with a few clients, and you configured the option I was referring to, after a few milliseconds or seconds, depending on your config, it will stop accepting writes. On the other side (in the majority side) a slave will get elected a master, and the clients will be able to write. When the partition heals all will be able to write to the new master.
About CP VS AP, I'll reply to another comment asking the same.