what if the node with active vbuckets down when it does not finish it’s TAP to replicas, when we rollback this node, does those TAP updates which we have not finished continue?
looks it does not log the process on disk, all progress would missed
what if it has been persisted in active node, does it will backfill data after active node reboot?
Hi there,
You mentioned 2 cases:
- #1: for the case where the data isn’t replicated to another node or persisted to local disk, you will loose the data in case the node goes down. Even if you bring the node back, the update to memory is lost with a restart of the process.
-
#2 for the case where you used persistTo flag and waited for the persistence to happen to local disk (persistto=1), if the node isn’t failed over and you bring the node back up, you will recover this data. However if you have auto failover, another node may take over and may not have the most up to date version of the vbucket. You can avoid this by specifying the replicateTo=1 flag. which will confirm the mutation only after replication has happened to 1 additional replica + the master vbucket.
Hope this answers your question.
thanks
-cihan
I don’t think so, if we specify the replicateto=1, when we write active success and all replica failed ,it return failed, but the active with new value, replica with old value, it is not consistent.( not strong consistent nor eventually consistent)
and replicateto means replicate to memory, node down also lose data on the node.
I dont think couchbase provide strong consistent which means all replicas with ACID, and does not provide eventually consistent neither, which means it will not loss data in any exceptions
I think we may have different definition of eventual consistency at play here. Could you describe what you mean by eventually consistency?
To clarify, ReplicateTo contract is to confirm only when we are sure that the change replicated but failure does not mean we were not able to write it for sure. However failure with replicateTo signals the app to retry the write. I’d not think of Couchbase consistency model in ACID terms - we are not transacting anything other than a single document write to a degree. However I’d say Couchbase is eventually consistent. That is simply based on this; one would not end up, in steady state, in a situation where replica and master disagrees on what the right value is. Obviously in a moving system this is hard to observe but in a system with no updates, you will end up with a consistent master and replica vbuckets.
eventually consistent stands for all replica will eventually consistent, say master replica down , and it would recopy those updates which has not been sent to replicas.
but couchbase here no mater replicateTo=1 or not, it will loss those updates which has not replicated yet if master replica down even if return back
Our definitions of eventual consistency seems slightly different.
Couchbase will eventually agree between replica and master. No worries there but what they will agree on will be based on who is elected to be the master and dictate the truth.
You mentioned this on your comment:
…say master replica down , and it would recopy those updates which has not been sent to replicas.
How would a system copy the updates from a down replica? like to understand that to make sure we can evaluate your input here.
I think you already understand this but to be crisp; with strict consistency through a distributed transaction you can get the assurance the update is either on both or none of the replicas/master. But that is expensive and slow. Our alternative here is to do eventual consistency with replicateTo=1. However if the update fails with replicateto=1, it means one of 2 things;
- we failed to write to master - replica will never get the value
- we did a write to master but we could not yet observe the write on the replica in the time window we allowed.
In the later case, to get the assurance, you need to retry your update. We provide a SET operation that is an up-sert (insert+update) operation that can give your app and easy way to retry.
I hope that clarifies the behavior. We do plan on building additional consistency options in future but that won’t happen with the upcoming release.
-cihan
thank you for the reply.
You’ve mentioned "How would a system copy the updates from a down replica? like to understand that to make sure we can evaluate your input here."
eventually system may do this way: master write mem and disk, with binlog to disk to tell the process of replication, after the reboot of master, replication continue from the last position, which make sure the eventual.
the other options would be to check the binlog checksum backend
at this point, i don’t think it is strong consistent as the Architecture Review declared, even not Eventually Consistent, or to say , not strictly.
couchbase do consistent in memory of replicas instead of persisted disk
…eventually system may do this way: master write mem and disk, with binlog to disk to tell the process of replication, after the reboot of master, replication continue from the last position, which make sure the eventual.
This is similar to what we do with persistTo=1. However if you do not choose to failover during the time the master is offline, you have unavailability to deal with. if you don’t fail over and promote another replica, you will get all things that were persisted with the persistTo=1 calls back.
wasn’t sure what you mean on your last post so not sure if you have a question there.
thanks
-cihan
as I have said in previous comment：
“eventually consistent stands for all replica will eventually consistent, say master replica down , and it would recopy those updates which has not been sent to replicas.
but couchbase here no mater replicateTo=1 or not, it will loss those updates which has not replicated yet if master replica down even if return back”
replicateTo=1 has a bad case: master write mem or persist success, and replication failed, it return fail, but master and replica is not consistent at this time , and will not eventually consistent.
although it has callback function to let client do sth. but the server itself should follow BASE protocol , and callback to write back the old value would fail as well
any one could explain and conclusion?