[seiji]

I am not convinced you know what you're doing

I feel you've read the aphyr writings, but didn't follow the story through to the end. He wasn't testing the systems entirely as they were designed to be used.

Sentinel is just a Redis-aware consensus driven failover service. Instead of writing your own "if master is unreachable, promote replica to master" script, Sentinel will do that for you and at the same time notify all your clients to switch to the new master. It's kinda nice that way.

Redis Cluster has very specific use cases. Not every distributed software doodad should be used in any situation we can imagine. Things have design goals. Used the right way, you get happy times. Used the wrong way, you get grumpy cat.

[lucian1900]

> 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?

[antirez]

> 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).

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.