Question about persistence and data loss during node crashing
Hello!
I'm a little bit confused about the couchbase bucket's persistence logic (especially in cases of node crashing). Not exactly sure what happens to the data already persisted (or partialy persisted) to a disk in several different scenarios. I'll give you examples.
Let's say I have a very simple configuration with only one node, only one couchbase bucket and no replication settings at all. And I also have an application that is trying to execute the following sequence of actions:
1. adding a new document X with value "x"
2. replacing the value of X with new value "y"
3. removing the document X by calling "delete"
When suddenly! Crashing event happens causing the node to reboot instantly and completely.
What state of data can I actually have after the reboot considering asynchronous nature of flushing to the disk?
From what I understand from the documentation sections the following statements seem valid:
A. reboot between 1 and 2 and before (or in the proccess of) flushing to the disk leaves me with no document X at all
B. reboot between 1 and 2 and after flushing to the disk - document X with "x" value
C. reboot between 2 and 3 and before (or in the proccess of) flushing to the disk - document X with "x" value (The C statement is the most confusing one.)
D. reboot between 2 and 3 and after flushing to the disk - document X with "y" value
E. reboot after 3 and before flushing to the disk - document X with "y" value
F. reboot after 3 and after flushing to the disk - no document X
Or these are not true?
It would be great if someone could clarify this topic to me :)
Thanks!
Thank you :)
Hello,
Some more questions to make things definitely clear for me :
Lets take the previous configuration, and add a second node to make it a cluster.
We still keep one single bucket, but we activate replication for each vBucket to the oposite node.
Is the following sequence true when a write (add, set, cas, etc... ) is made from a client application :
Step 1 : The write is made on the source node and stored in RAM
Step 2 : The write is then acknowledged to the client app
Step 3 : Then the write is placed in both the local disk queue and the replication queue (Is this done in sequence or in parallel ?)
Step 4 : The write will eventually be written to disk on the source node and eventually be propagated to the replica node (in whichever order)
If the previous sequence is true, does it mean that when a failure occurs on the source node after step 2 but before step 3, the write will be lost for ever ?
Are the disk queue and replication queue only "stored" in RAM or are they persisted to disk in some synchronous ways before step 2 ?
If a failure occurs on the source node after step 3 but before step 4, will the "source node" be able to recover this write when put back into service ?
Regarding Couchbase 2.0, is it confirmed that there is no "Optional Synchronous Replication" ?
I am sure i have read this before but can't find it anymore : Is there anyway to make synchronous write from the client and get the acknowledge only when the data is written to the local disk or sent to the replica node ?
Many thanks
I believe you got it correct. This is also why we have replication, so that if a node crashes before written by disk write queue, it's also in replica node in RAM and that nodes' disk write queue.
@scalabl3
Technical Evangelist
Couchbase Inc.