How data will be consistent on cassandra cluster

Question

I have a doubt when i read datastax documentation about cassandra write consistency. I have a question on how cassandra will maintain consistent state on following scenario:

• Write consistency level = Quorum
• replication factor = 3

As per docs, When a write occurs coordinator node will send this write request to all replicas in a cluster. If one replica succeed and other fails then coordinator node will send error response back to the client but node-1 successfully written the data and that will not be rolled back.

In this case,

Will read-repair (or hinted-handoff or nodetool repair) replicate the inconsistent data from node-1 to node-2 and node-3?

If not how will cassandra takes care of not replicating inconsistent data to other replicas?

Can you please clarify my question

Crybaby

Answer 1

You are completely right, the read repair or other methods will update the node-2 and node-3. This means even the failed write will eventually update other nodes (if at least one succeeded). Cassandra doesn't have anything like rollback that relational databases have.

Playbill

How we can overcome from this issue. I don't want my user see messages in his inbox which was failed while submission. Is there any workaround for that to avoid this issue? – Crybaby

I am not aware of any way to avoid this, but what you can do is in failed writes try again. this only works if enough nodes for that partition key are available, otherwise the write will fail again. one option is to reduce the write consistency level for the second write to one. – Playbill

Thanks for your update. I hope Cassandra will come up with some solution. – Crybaby

Answer 2

I don't see there is anything wrong - the system does what you tell it, i.e., two override one, and since the error messages sent back to the client as "fail", then the ultimate status should be "fail" by read repair tool.

Behnken

Answer 3

Cassandra Coordinator node maintains the failed replica data in its storage and it will retry periodically (3 times or so) then if it succeeds then it will send the latest data, otherwise it will truncate the data in its storage.

In case of any read query, Coordinator node sends requests to all the replica nodes, and it will compare the results from all the replica nodes. If one of the replica node is not sending the latest data, then it will send read repair command to that node in order to keep the nodes in sync.

Diffuse