question

Shalini Ramachandra avatar image
Shalini Ramachandra asked Erick Ramirez commented

When a write timeout occurs, does it mean the subsequent read will fail?

Hi @Erick Ramirez, I was reading this answer from you: https://community.datastax.com/questions/5647/coordinator.html# about write consistency levels and the exceptions that drivers report. I was curious about this one in particular:

WriteTimeoutException: Cassandra timeout during SIMPLE write query at consistency LOCAL_QUORUM (2 replica were required but only 1 acknowledged the write)" 

This simply means that there was a delay in ack from 1 replica, but does not necessarily mean that the write itself failed on that replica. If I understand it right, it's now up to the application on how to handle this error.

From what I've understood so far, there are multiple cases here:

  1. Writes were successful on both replicas, but one of the replica did not respond with ack in time, to the coordinator.
  2. The data was written successfully on one replica, but not on the other. But since the data was written to one of the replicas, eventually the other replica would also get the data. So even if the application did not act on this error, data would eventually be consistent on the 2 replicas, by means of hinted-handoffs (?) / read repairs.

Could you please let me know if my understanding is right? If not, please correct me :)

What will happen if a write timeout occurs, on the subsequent read request? My writes are EACH_QUORUM and reads are LOCAL_QUORUM

cassandraconsistency level
10 |1000

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

1 Answer

Erick Ramirez avatar image
Erick Ramirez answered Erick Ramirez commented

I don't know what you mean by "... subsequent read ..." when a write timeout occurs. There is no write-before-read in Cassandra.

In any case, I'll respond to the other points you raised.

This assumption is incorrect:

Writes were successful on both replicas, but one of the replica did not respond with ack in time, to the coordinator.

How do you know that the writes were "successful on both replicas"? And how would you know which 2 replicas they were? Your understanding is incorrect.

This is also incorrect:

The data was written successfully on one replica, but not on the other.

Mutations are sent to all replicas (in all DCs) by the coordinator. It is not just sent to 2 nodes. This error means that there were 3 local replicas (RF=3), 2 of those replicas were required to acknowledge the write for LOCAL_QUORUM but only 1 responded:

WriteTimeoutException: Cassandra timeout during SIMPLE write query at consistency LOCAL_QUORUM (2 replica were required but only 1 acknowledged the write)

Eventual consistency does not apply here so this is incorrect:

But since the data was written to one of the replicas, eventually the other replica would also get the data. So even if the application did not act on this error, data would eventually be consistent on the 2 replicas, by means of hinted-handoffs (?) / read repairs.

To be clear, the required consistency level was NOT met so the write request failed. The data does not exist in the database since the write was not successful. Cheers!

2 comments Share
10 |1000

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Shalini Ramachandra avatar image Shalini Ramachandra commented ·

Thanks for correcting my assumptions @Erick Ramirez.

I understand that out of the 3 local replicas, if only one acknowledged the write, then we really aren't sure what happened to the other 2. So the "required consistency level is not met"

But since one of the replicas acknowledged the write, doesn't it mean that data was definitely written to this "one replica"? I don't clearly understand when you say "data does not exist in the database". The coordinator is not triggering any "rollback" on the data that was written as such, correct?

0 Likes 0 ·
Erick Ramirez avatar image Erick Ramirez ♦♦ Shalini Ramachandra commented ·

I think you've missed the point -- writes are only successful if they required consistency level is met. If Cassandra ignores the CL then there's no point setting it. Cheers!

1 Like 1 ·