Snapshots trigger a flush first, so data that's currently in the commit log will be covered by the snapshot.
On Thu, Dec 6, 2012 at 11:52 PM, Andrey Ilinykh <ailin...@gmail.com> wrote: > > > > On Thu, Dec 6, 2012 at 7:34 PM, aaron morton <aa...@thelastpickle.com>wrote: > >> For background >> >> >> http://wiki.apache.org/cassandra/Operations?highlight=%28snapshot%29#Consistent_backups<http://wiki.apache.org/cassandra/Operations?highlight=(snapshot)#Consistent_backups> >> >> If you it for a single node then yes there is a chance of inconsistency >> across CF's. >> >> If you have mulitple nodes the snashots you take on the later nodes will >> help. If you use CL QUOURM for reads you *may* be ok (cannot work it out >> quickly.). If you use CL ALL for reads you will be ok. Or you can use >> nodetool repair to ensure the data is consistent. >> >> I'm talking about restoring whole cluster, so all nodes are restored from > backup and all of them are inconsistent because they lost data from commit > logs. It doesn't matter what CL I use, some data may be lost. > Cassandra 1.1 supports commit log archiving > http://www.datastax.com/docs/1.1/configuration/commitlog_archiving > I think if I store both flushed sstables and commit logs it should solve > my problem. I'm wondering if someone has any experience with this feature? > > Thank you, > Andrey > -- Tyler Hobbs DataStax <http://datastax.com/>
