DataStax Academy FAQ

DataStax Academy migrated to a new learning management system (LMS) in July 2020. We are also moving to a new Cassandra Certification process so there are changes to exam bookings, voucher system and issuing of certificates.

Check out the Academy FAQ pages for answers to your questions:


question

Shalini Ramachandra avatar image
Shalini Ramachandra asked ·

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 characters needed characters left characters exceeded

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 ·

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 characters needed characters left characters exceeded

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

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 · ·

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 · ·