Cassandra - Client Timestamp and Conflict Recognition

4
votes

Cassandra's last write policy is based on timestamp, and this is the client timestamp. It is possible that time between clients is not synchronised - this can cause lost updates. I would like to exactly know what happens in flowing scenarios:

  • Client clock is delayed few years - in this case column update send from this hardly delayed client has always older timestamp, when compared to already existing value (created by "normal" client). Will Cassandra ignore such update? Will this update overwrite existing column value, and set older time?
  • Client gains few years - in this case, update from this client will always win, in case of concurrent write request executed from another "correct" client - correct?
2
cassandra

2 Answers

3
votes

Yes, the timestamps are used for conflict resolution, so newer timestamps always win. The general recommendation is to run ntp on all your machines.

If for some reason ntp isn't an option, you can set the timestamp to what ever value you want on the client, but you would have to devise your own way of synchronizing that value (getting ntp working will almost always be easier).

1
votes

I wrote a post about Cassandra Timestamps a while ago. It discusses conflict situations.