Some RDBMS actual perform background asynchronous replication. If you're doing your reads from slaved replicas, you've got an "eventually consistent" system ("A{possibly, P}"). If you're only doing reads from the master node, you're no longer highly available. If you're "promoting" slaves in the case of a master failing, you're _AT_ best back to the case of eventual consistency (if the master comes back and the replication backlog is replayed correctly) or you might not be consistent at all. To echo others, let's call this "potential consistency".
Eventual consistency isn't something Amazon decided to make up, we've dealt with eventually consistent systems on a daily basis long before (DNS, usenet, some distributed file systems, etc...).
BigTable and co. are not "CP" and much more true to the "CA" definition than say MySQL replication or Postgres + Slony. They use protocols like Paxos with leases (BigTable) and Zab (used by ZooKeeper based systems). These are modified 3PC protocols: unlike 2PC protocols, they still guarantee fault tolerance ("A") even if the coordinator node fails; unlike pure 3PC protocols they offer certain guarantees of liveliness (e.g., through the use of leases) and even some degree of partition tolerance. Still, Google had to build Spanner on top of BigTable to provide partition tolerance / true multi-datacenter operation.
> If you're "promoting" slaves in the case of a master failing, you're again back to the case of eventual consistency.
I don't think so. If you use asynchronous replication and the master fails directly after acknowledging a new request but before forwarding it to the slaves, this request may be totally lost. So you'd have no consistency at all (or at least not eventual consistency).
Comments
This doesn't look entirely right to me.
Some comments:
Some RDBMS actual perform background asynchronous replication. If you're doing your reads from slaved replicas, you've got an "eventually consistent" system ("A{possibly, P}"). If you're only doing reads from the master node, you're no longer highly available. If you're "promoting" slaves in the case of a master failing, you're _AT_ best back to the case of eventual consistency (if the master comes back and the replication backlog is replayed correctly) or you might not be consistent at all. To echo others, let's call this "potential consistency".
Eventual consistency isn't something Amazon decided to make up, we've dealt with eventually consistent systems on a daily basis long before (DNS, usenet, some distributed file systems, etc...).
BigTable and co. are not "CP" and much more true to the "CA" definition than say MySQL replication or Postgres + Slony. They use protocols like Paxos with leases (BigTable) and Zab (used by ZooKeeper based systems). These are modified 3PC protocols: unlike 2PC protocols, they still guarantee fault tolerance ("A") even if the coordinator node fails; unlike pure 3PC protocols they offer certain guarantees of liveliness (e.g., through the use of leases) and even some degree of partition tolerance. Still, Google had to build Spanner on top of BigTable to provide partition tolerance / true multi-datacenter operation.
> If you're "promoting" slaves in the case of a master failing, you're again back to the case of eventual consistency.
I don't think so. If you use asynchronous replication and the master fails directly after acknowledging a new request but before forwarding it to the slaves, this request may be totally lost. So you'd have no consistency at all (or at least not eventual consistency).
My bad. Editing the original comment. You're completely right, I forgot the case of master failing before all writes made to it are replicated.