5 ms·

Most (but not all) MySQL / PostgreSQL HA systems have similar semantics of Redis Sentinel. They don't try to achieve any linearizable semantics, but to perform

by antirez 11y ago

Most (but not all) MySQL / PostgreSQL HA systems have similar semantics of Redis Sentinel. They don'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's up to the product requirements to understand if it is ok that a given set of failure modes produce data loss and/or inconsistencies) but the important bit is that the semantics is very well documented so that users know what tradeoffs they are making. 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: 1. It's distributed so Sentinel itself is not a single point of failure. 2. When the partition heals Sentinel is able to have a coherent view of the configuration. 3. It is able to automatically reconfigure the old master and the other slaves to replicate from the new master. 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.

contingencies 11y ago
Generic solutions like corosync/pacemaker also deserve a mention. At some point you need inter-service dependencies, floating IPs, hot service spares and ordered recovery, plus tolerance for network fabric faults. Not every daemon needs to implement this stuff!
lucian1900 11y ago
A large reason to use Postgres in the first place is because it's a good CP system. Any clustered version is only worthwhile if it preserves consistency. It's already possible to use more than one Postgres database while not maintaining consistency, but that isn't desirable for most users.
- antirez 11y ago
  > it's a good CP system PostgreSQL is not clustered by default so it is only from the point of view of the theory a CP system. Most proper CP systems have the ability to provide a limited form of Availability, which is, they are available in the majority partition (this is not "A" of CAP but is a lot better than, if primary is not available, the whole cluster is not available). If you use PostreSQL with asynchronous replication and a best-effort failover solution to provide some form of Availability, you are doing something that makes sense, assuming your product can tolerate the resulting weak consistency properties. This is a great example on how CAP does not capture certain important semantics of a system. Technically a single primary node is CP but the real world CP systems have better availability than that, or they are useless (as CP systems).
- takeda 11y ago
  There are two separate problems: - clustering to increase performance - clustering for HA Most people want at least the later one. The former one is a bigger challenge in case of relational databases so I'll ignore it here. Regarding consistency vs availability typically is not all black and white, and people are willing to make tradeoff. For example losing few transactions as opposed to being completely down. This is not too bad as long as developers are aware of that special case and write code that can handle that. Having said that, I'm wondering how a failover system based on BookKeeper[1] would work (a relational database is effectively a state machine, so seems like this could fit). The tradeoff here would be most likely reduced performance though. [1] http://bookkeeper.apache.org/ http://bookkeeper.apache.org/
SEJeff 11y ago
Would you be willing to run Jepsen again yourself with the latest Sentinel, or ask aphyr/Kyle to run it again himself?
- fweespeech 11y ago
  I think you are missing the point. Sentinel isn't really meant to solve what Aphyr/Jepsen tests.
angelbob 11y ago
Redis Sentinel's semantics are an excellent solution for what I use Redis for. Redis Sentinel's semantics are a terrible solution for things I use relational DBs for. The fact that clustered relational systems accepts transactions in SQL and then just handle them wrong is completely unacceptable. Redis has the advantage of making it pretty darn clear that it's best-effort, simple ops, non-transactional. If you spent all your time bragging about ACID semantics for Redis, we'd rake you over the coals at least as hard. (And you don't. Thanks for that! Also, Redis is awesome.)

by antirez 11y ago

contingencies 11y ago

Generic solutions like corosync/pacemaker also deserve a mention. At some point you need inter-service dependencies, floating IPs, hot service spares and ordered recovery, plus tolerance for network fabric faults. Not every daemon needs to implement this stuff!

lucian1900 11y ago

A large reason to use Postgres in the first place is because it's a good CP system. Any clustered version is only worthwhile if it preserves consistency. It's already possible to use more than one Postgres database while not maintaining consistency, but that isn't desirable for most users.

antirez 11y ago
> it's a good CP system PostgreSQL is not clustered by default so it is only from the point of view of the theory a CP system. Most proper CP systems have the ability to provide a limited form of Availability, which is, they are available in the majority partition (this is not "A" of CAP but is a lot better than, if primary is not available, the whole cluster is not available). If you use PostreSQL with asynchronous replication and a best-effort failover solution to provide some form of Availability, you are doing something that makes sense, assuming your product can tolerate the resulting weak consistency properties. This is a great example on how CAP does not capture certain important semantics of a system. Technically a single primary node is CP but the real world CP systems have better availability than that, or they are useless (as CP systems).
takeda 11y ago
There are two separate problems: - clustering to increase performance - clustering for HA Most people want at least the later one. The former one is a bigger challenge in case of relational databases so I'll ignore it here. Regarding consistency vs availability typically is not all black and white, and people are willing to make tradeoff. For example losing few transactions as opposed to being completely down. This is not too bad as long as developers are aware of that special case and write code that can handle that. Having said that, I'm wondering how a failover system based on BookKeeper[1] would work (a relational database is effectively a state machine, so seems like this could fit). The tradeoff here would be most likely reduced performance though. [1] http://bookkeeper.apache.org/ http://bookkeeper.apache.org/

SEJeff 11y ago

Would you be willing to run Jepsen again yourself with the latest Sentinel, or ask aphyr/Kyle to run it again himself?

fweespeech 11y ago
I think you are missing the point. Sentinel isn't really meant to solve what Aphyr/Jepsen tests.

angelbob 11y ago

Redis Sentinel's semantics are an excellent solution for what I use Redis for. Redis Sentinel's semantics are a terrible solution for things I use relational DBs for. The fact that clustered relational systems accepts transactions in SQL and then just handle them wrong is completely unacceptable. Redis has the advantage of making it pretty darn clear that it's best-effort, simple ops, non-transactional. If you spent all your time bragging about ACID semantics for Redis, we'd rake you over the coals at least as hard. (And you don't. Thanks for that! Also, Redis is awesome.)