Right. I don't personally think incremental backup is useful beyond restoring individual nodes unless none of your data happens to reference any other rows.
--On Fri, Dec 7, 2012 at 11:37 AM, Andrey Ilinykh <email@example.com> wrote:That's right. But when I have incremental backup on each CF gets flushed independently. I have "hot" CF which gets flushed every several minutes and regular CF which gets flushed every hour or so. They have references to each other and data in sstables is definitely inconsistent.On Fri, Dec 7, 2012 at 9:28 AM, Tyler Hobbs <firstname.lastname@example.org> wrote:
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 <email@example.com> wrote:
On Thu, Dec 6, 2012 at 7:34 PM, aaron morton <firstname.lastname@example.org> wrote:
For backgroundIf 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 archivingI 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