cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <>
Subject Re: Consistent problem when solve Digest mismatch
Date Mon, 04 Mar 2013 15:09:44 GMT
The problem is, what is the sequence number you are talking about is

Or let me put it another way: if you do have a sequence number that
provides a total ordering of your operation, then that is exactly what you
should use as your timestamp. What Cassandra calls the timestamp, is
exactly what you call seqID, it's the number Cassandra uses to decide the
order of operation.

Except that in real life, provided you have more than one client talking to
Cassandra, then providing a total ordering of operation is hard, and in
fact not doable efficiently. So in practice, people use unix timestamp
(with ntp) which provide a very good while cheap approximation of the real
life order of operations.

But again, if you do know how to assign a more precise "timestamp",
Cassandra let you use that: you can provid your own timestamp (using unix
timestamp is just the default). The point being, unix timestamp is the
better approximation we have in practice.


On Mon, Mar 4, 2013 at 9:26 AM, Jason Tang <> wrote:

> Hi
>   Previous I met a consistency problem, you can refer the link below for
> the whole story.
>   And after check the code, seems I found some clue of the problem. Maybe
> some one can check this.
>   For short, I have Cassandra cluster (1.0.3), The consistency level is
> read/write quorum, replication_factor is 3.
>   Here is event sequence:
> seqID   NodeA   NodeB   NodeC
> 1.         New      New       New
> 2.         Update  Update   Update
> 3.         Delete   Delete
> When try to read from NodeB and NodeC, "Digest mismatch" exception
> triggered, so Cassandra try to resolve this version conflict.
> But the result is value "Update".
> Here is the suspect root cause, the version conflict resolved based
> on time stamp.
> Node C local time is a bit earlier then node A.
> "Update" requests sent from node C with time stamp 00:00:00.050, "Delete"
> sent from node A with time stamp 00:00:00.020, which is not same as the
> event sequence.
> So the version conflict resolved incorrectly.
> It is true?
> If Yes, then it means, consistency level can secure the conflict been
> found, but to solve it correctly, dependence one time synchronization's
> accuracy, e.g. NTP ?

View raw message