Assuming we are using periodic mode for commit log sync.
On Wed, Apr 5, 2017 at 3:29 PM, preetika tyagi
wrote:
> Very good explanation.
> One follow-up question. If CL is set to 1 and RF to 3, then there are
> chances of the data being lost if the machine crashes before replication
> happens and
Very good explanation.
One follow-up question. If CL is set to 1 and RF to 3, then there are
chances of the data being lost if the machine crashes before replication
happens and the commit log (on the node which processed the data for CF=1)
is not synced yet. Right?
Thanks,
Preetika
On Wed, Apr 5
I beg to differ with @Matija here, IMO by default cassandra syncs data into
commit log in a periodic fashion with a fsync period of 10 sec (Ref -
https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L361).
If a write is not written to disk and RF is 1 else CL is Local One & node
goes
Flushes have nothing to do with data persistence and node failure. Each
write is acknowledged only when data has been written to the commit log AND
memtable. That solves the issues of node failures and data consistency.
When the node boots back up it replays commit log files and you don't loose
dat
Hi,
I read in Cassandra architecture documentation that if a node dies and
there is some data in memtable which hasn't been written to the sstable,
the commit log replay happens (assuming the commit log had been flushed to
disk) when the node restarts and hence the data can be recovered.
However,
