incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Coli <rc...@palominodb.com>
Subject Re: Using the commit log for external synchronization
Date Fri, 21 Sep 2012 23:39:10 GMT
On Fri, Sep 21, 2012 at 4:31 AM, Ben Hood <0x6e6562@gmail.com> wrote:
> So if I understand you correctly, one shouldn't code against what is
> essentially an internal artefact that could be subject to change as
> the Cassandra code base evolves and furthermore may not contain the
> information an application thinks it should contain.

Pretty much.

> So in summary, given that there is no out of the box way of saying to
> Cassandra "give me all mutations since timestamp X", I would either
> have to go for an event driven approach or reconsider the layout of
> the Cassandra store such that I could reconcile it in an efficient
> fashion.

With :

https://issues.apache.org/jira/browse/CASSANDRA-3690 - "Streaming
CommitLog backup"

You can stream your commitlog off-node as you write it. You can then
restore this commitlog and tell cassandra to replay the commit log
"until" a certain time by using "restore_point_in_time". But...
without :

https://issues.apache.org/jira/browse/CASSANDRA-4392 - "Create a tool
that will convert a commit log into a series of readable CQL
statements"

You are unable to skip bad transactions, so if you want to
roll-forward but skip a TRUNCATE, you are out of luck.

The above gets you most of the way there, but Aaron's point about the
commitlog not reflecting whether the app met its CL remains true. The
possibility that Cassandra might coalesce to a value that the
application does not know was successfully written is one of its known
edge cases...

=Rob

-- 
=Robert Coli
AIM&GTALK - rcoli@palominodb.com
YAHOO - rcoli.palominob
SKYPE - rcoli_palominodb

Mime
View raw message