Most (but not all) MySQL &#x2F; PostgreSQL HA systems have similar semantics of Redis Sentinel. They don&#x27;t try to achieve any linearizable semantics, but to perform failure detection and fail over to some slave, with heuristics about what slave to pick. All this kind of solutions will fail to pass Jepsen tests since they are not designed to achieve the kind of strong properties Jepsen will test for. The behavior of those systems is acceptable in many production situations (it&#x27;s up to the product requirements to understand if it is ok that a given set of failure modes produce data loss and&#x2F;or inconsistencies) but the important bit is that the semantics is very well documented so that users know what tradeoffs they are making.<p>EDIT: Shameless plug: I believe it was a shame that Sentinel was initially badly received because of the Jepsen test (now tons of users are using Sentinel with success, fortunately), since for what it does, it is very advanced compared to * SQL failover solutions, so a porting of Redis Sentinel to failover those systems could make sense IMHO. A few things Sentinel has that are desirable in * SQL failover systems:<p>1. It&#x27;s distributed so Sentinel itself is not a single point of failure.<p>2. When the partition heals Sentinel is able to have a coherent view of the configuration.<p>3. It is able to automatically reconfigure the old master and the other slaves to replicate from the new master.<p>4. It is able to work as a configuration provider for clients, with a well defined handshake in order to trigger the reconfiguration of all the clients.