Support asynchronous-replication

replication

(kyu) #1

Why doesn’t CRDB support async-replication? In order to guarantee consistency for cross-row transaction?

Is it hard to implement cross-row transaction if replication is asynchronous.
e.g.: a transaction commit two rows on two nodes, if nodeA has replicated to slave, and another one(nodeB) crash before replicate completely.
So, transaction is not consistency.

am i right?


(Tim O'Brien) #2

Hi @ken,

If I understand your question correctly, that’s not quite right.

You wouldn’t use two nodes if you wanted to tolerate a node failure, you’d use three. In that case, every node has a copy of the data. You can lose one, and we can still maintain consistency.

I’d recommend reviewing our architecture docs if you want to understand more, specifically the replication layer, transaction layer, and secret life of data presentation.


(Raphael 'kena' Poss) #3

@ken please also understand that CockroachDB does use asynchronous replication – txn only need 2 nodes out of 3 to acknowledge a write; the last node can get a copy of the data only later, i.e. asynchronously.


(kyu) #4

Sorry, I may not have described clearly.
My questions are:

  1. We needn’t raft in some cases,(maybe needn’t repliation, maybe need only one replication)
  2. Is it hard to implement cross-row transaction if replication is asynchronous ?

CRDB is using raft consensus algorithm, so 3 is the smallest number that can achieve quorum.
In most cases, we needn’t raft, asyn-replication is enough for us, like mysql-async-replication mechnism.
For unimportant data, maybe we needn’t replication, for more important, maybe we only need one replication(it depends). That is to say, we needn’t quorum.


(Raphael 'kena' Poss) #5

Then CockroachDB is not the database you need. Have you considered MongoDB? Or active-passive PostgreSQL?


(kyu) #6

i known that is not a database i want.
but i am curious my question2.
can you help to answer my question2 . thanks a lot.


(Raphael 'kena' Poss) #7

Cross-row transactions and replications are two independent concepts.

Depending on your database design, it can be hard to implement cross-row transactions if replication is asynchronous.

Depending on your database design, it can be easy to implement cross-row transactions if replication is asynchronous.

Depending on your database design, it can be hard to implement cross-row transactions if replication is synchronous.

Depending on your database design, it can be easy to implement cross-row transactions if replication is synchronous.

See, all 4 possibilities exist.


(kyu) #8

I think multi-row transactions and replications are indirect relation.
If you wanna guarantee consistency(ACID) of transactions, it’s impossible to use asynchronous.
e.g.: a transaction commit two rows on two nodes, if nodeA has replicated to slave, and another one(nodeB) crash before replicate completely.


(Raphael 'kena' Poss) #9

Again see my answer from above: CockroachDB does use asynchronous replication – a transaction only need 2 nodes out of 3 to acknowledge a write; the last node will get a copy of the data only later, i.e. asynchronously.

So CockroachDB provides both ACID guarantees on multi-row transactions, and asynchronous replication.

Is there anything else you’d like to know?


(kyu) #10

If a transaction only need 1 nodes out of 3 to acknowledge a write; the last two nodes will get a copy of the data only later, is it impossible guarantee ACID


(Bob Vawter) #11

It certainly fails Durability, should that single node fail.

The real problem is Consistency. Consider the following case:

  • Your database cluster of three nodes suffers a network partition, rendering each node unable to talk to another.
  • Client 1 tries to update row R and only node 1 accepts the write.
  • Client 2 simultaneously tries to update row R and only node 2 accepts the write.
  • The network partition is corrected.

Which client’s write to row R is definitive?


(kyu) #12

yup,
If replication is asynchronous, must tolerate inconsistency, but depend on how do you implement it.
If master(or leader) has been mark as failed(or it can’t ping others nodes or coordinator), it should stop accepting requests. And clients should be notified.