[
https://issues.apache.org/jira/browse/CASSANDRA-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111403#comment-14111403
]
Aleksey Yeschenko commented on CASSANDRA-7835:
----------------------------------------------
Yeah, catastrophic cluster failure is not what batchlog was designed for. It
was designed to handle coordinator failure mid-request. Read Jonathan's
original blog post
(http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2). It's not
there for availability. Proper replication config + proper consistency levels
should be used for that. And if you can't accept the current situation, you'd
have to retry manually, until the request is complete, and not consider the
request 'done' until you get a successful response from one of the retries.
As for spanning multiple keyspaces - again, same reasoning. Although we do try
to pick batchlog nodes from different racks if possible since CASSANDRA-6551.
I think you are slightly misunderstanding the purpose/inner workings of the
batchlog, here.
> Atomic batches with an option to specifcy RF-1 batch log entries
> ----------------------------------------------------------------
>
> Key: CASSANDRA-7835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7835
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ryan Svihla
> Priority: Minor
>
> Some users seem to be concerned with there only being 2 batch log entries on
> a write and would like more guarantees on consistency, potentially even
> spanning data centers in exchange for less performance.
> Would like the option to have these span data centers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
