4 ms·

A replica always lags master by some degree. It may be small—until things go sideways—but it's still another form of eventual consistency.

peterwwillis 9y ago
You're saying ACID databases are eventually consistent?
- saryant 9y ago
  I'm saying read replicas are not instantly in sync with their masters. Updates are asynchronously copied to the replica.
  - peterwwillis 9y ago
    Or, you know, use synchronous replication, or semi-synchronous, or a different asynchronous model that isn't weakly consistent such as distributed transaction logs, write-read consensus, complicated locking mechanisms, etc
    - saryant 9y ago
      All of these solutions are still battling the fact that distributed systems are hard and there's a tradeoff to every decision. If you use synchronous replication, you now require at least two systems to commit a write, so you've increased the chance that your commit will fail. Maybe that's the right choice—but it's a tradeoff and the decision ultimately rests in your business requirements. My point is simply that there is no magic bullet in ensuring that all relevant systems have the same answer to the same question at the same time.
      - deleted 9y ago
        [deleted]
- derefr 9y ago
  They can be. Multi-master DB clusters, unless they're built on consensus (and boy how slow that would be), usually are. Read-replicas, though, don't have much to do with that; a read-replica is essentially a point-in-time snapshot of the DB, that's going to get replaced with an updated snapshot every few milliseconds as WAL-log events stream in. That isn't "eventually consistent"; it's just "inconsistent." You're always looking at the past when you're talking to a read-replica. If you need to update values using a client-side calculation, you'll need to do all that in a single transaction to get ACID guarantees. Since a transaction can only be "against" one node, and since the transaction will contain a write, that transaction (including both its reads and its writes) is forced to happen against a master node. A read-replica just isn't involved in the writing "story."

peterwwillis 9y ago

You're saying ACID databases are eventually consistent?

saryant 9y ago
I'm saying read replicas are not instantly in sync with their masters. Updates are asynchronously copied to the replica.
- peterwwillis 9y ago
  Or, you know, use synchronous replication, or semi-synchronous, or a different asynchronous model that isn't weakly consistent such as distributed transaction logs, write-read consensus, complicated locking mechanisms, etc
  - saryant 9y ago
    All of these solutions are still battling the fact that distributed systems are hard and there's a tradeoff to every decision. If you use synchronous replication, you now require at least two systems to commit a write, so you've increased the chance that your commit will fail. Maybe that's the right choice—but it's a tradeoff and the decision ultimately rests in your business requirements. My point is simply that there is no magic bullet in ensuring that all relevant systems have the same answer to the same question at the same time.
    - deleted 9y ago
      [deleted]
derefr 9y ago
They can be. Multi-master DB clusters, unless they're built on consensus (and boy how slow that would be), usually are. Read-replicas, though, don't have much to do with that; a read-replica is essentially a point-in-time snapshot of the DB, that's going to get replaced with an updated snapshot every few milliseconds as WAL-log events stream in. That isn't "eventually consistent"; it's just "inconsistent." You're always looking at the past when you're talking to a read-replica. If you need to update values using a client-side calculation, you'll need to do all that in a single transaction to get ACID guarantees. Since a transaction can only be "against" one node, and since the transaction will contain a write, that transaction (including both its reads and its writes) is forced to happen against a master node. A read-replica just isn't involved in the writing "story."