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 data that was already written to that node.
On Wed, Apr 5, 2017 at 6:22 PM, preetika tyagi <preetikaty...@gmail.com> wrote: > 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, I was wondering if a node is fully dead for some reason with > consistency level 1 (replication factor 3 but let's say it dies right after > it finishes a request and hence the data hasn't been replicated to other > nodes yet) and the data is only available in commit log on that node. Is > there a way to recover data from this node which includes both sstable and > commit log so that we can use it to replace it with a new node where we > could replay commit log to recover the data? > > Thanks, > Preetika >
