Thanks, what confuses me though is why you must retain n/2 hosts, and not be able to recover at least in many cases from a loss down to a single host. I understand that a known majority insures that a write will always persist/propagate even after a network segmentation and later re-join. But what if the network isn't segmented but the servers are simply down, or there wouldn't be a conflict regardless because the relevant clients couldn't have written to the segmented network anyway? When they rejoin they would all know they are behind the one that remained online (as one does with version clocks), so they could just get all missing events and be consistent again.
The majority requirement would, seems to me, reduce reliability over the ability to failover down to a single server.
Does anyone know of a list or test suite of all failures that a consistency algorithm is resistant too, then at least I could understand the reasoning. I get the impression that there are a lot of failure modes that are handled at some cost, but are not relevant to my use cases.
In a leader election, a node won't vote for a candidate that doesn't have a record it believes to be committed. Thus, writing to a majority ensures that when the leader dies, the new leader will have all the committed dats. Thus, up to n/2 - 1 nodes can be lost with a guarantee that no committed data is lost.
If you don't need strong consistency (after a write commits, all future reads will see the write), you can use simpler replication strategies.
Redis, for example, using async replication, that is not guaranteed to succeed. A redis master may ack a write, and a subsequent read may see it, but a loss of the master before replication occurs can result in data loss. The failover is not guaranteed to contain all writes. Some times weak consistency is ok. Sometimes it's not, but eventual consistency is ok. Other times strong consistency is needed.
Raft is useful when you need strong consistency.
Raft does support membership changes (adding and removing nodes from the cluster), so it can support losing more than n / 2 - 1 nodes, just not simultaneously.
The majority requirement would, seems to me, reduce reliability over the ability to failover down to a single server.
Does anyone know of a list or test suite of all failures that a consistency algorithm is resistant too, then at least I could understand the reasoning. I get the impression that there are a lot of failure modes that are handled at some cost, but are not relevant to my use cases.