cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sumsion <Sumsio...@familysearch.org>
Subject Consistency level used when applying atomic batches
Date Tue, 24 Jun 2014 16:43:35 GMT
The atomic batches feature is all about moving the multi-statement application to the server
side to avoid having to worry about retry logic on the client side.  I'm glad that the client
doesn't have to worry about it.

An earlier thread about consistency level and atomic batches broke the execution of atomic
batches into two steps (with an assumed final 3rd step):
1) writing the batch to the batch log
2) applying the individual statements in the batch
3) deleting the batch from the batch log

The question for me is what #2 does, and what guarantees are in place if the batch execution
returns successfully.  In addition, I wondered how the consistency level used when executing
the batch affects what is done in step #2.

>From what I can tell from cassandra server code, there is an additional step #0, and there
are more guarantees than I thought.

http://fossies.org/linux/misc/apache-cassandra-2.0.8-src.tar.gz/apache-cassandra-2.0.8-src/src/java/org/apache/cassandra/service/StorageProxy.java#l_537

Here is a revised and enhanced order of operations:
a) pre-check replicas for all statements in the batch, assuring that the correct number of
nodes are available for the consistency level passed from the client with the batch
b) write batch to 2 nodes in the local datacenter, unless you have a single-node datacenter
and use CL.ANY, and wait until those writes are complete -- where the batch is written, and
how many copies of the batch are written has nothing much to do with the consistency level
passed from the client with the batch -- an attempt is made to get two nodes from two separate
racks to write the batch
c) for each statement in the batch, execute that statement with the consistency level passed
from the client with the batch, and wait until the consistency level is satisfied on those
writes
d) remove the batch from where it had been written, but don't wait

This is interesting, because there are a few guarantees here:
- step a) implies that no writes (including the batch) will occur if any consistency-level-required
replica is unavailable right before starting to submit the writes
- step c) implies that all writes will be complete using the consistency level passed with
the batch
- steps a), b), and c) will be complete BEFORE the batch execution is acknowledged to the
client

If I've understood this correctly, please let me know.  If I've come to the wrong conclusions,
please help me understand.

John...


 NOTICE: This email message is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by reply email
and destroy all copies of the original message.


Mime
View raw message