[
https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434248#comment-13434248
]
Jonathan Ellis commented on CASSANDRA-4542:
-------------------------------------------
Summary of discussion from CASSANDRA-4285:
{code}
CREATE TABLE batchlog (
coordinator inet,
id uuid,
data blob,
PRIMARY KEY ((coordinator, shard))
) WITH gc_grace_seconds=0;
{code}
abm adds extra steps before and after writing a batch.
Before writing the batch (but *after* doing availability check against the FD
for the row replicas): write the entire batch to a batchlog elsewhere in the
cluster.
After: remove the batchlog entry (after writing hints for the batch rows, if
necessary).
The batchlog itself should be defined with LocalStrategy. Replay will be
handled locally (CASSANDRA-4543). Thus, we can't use the defined
ReplicationStrategy when writing to the BL from StorageProxy; we should pick
replicas manually:
- replicas should be in the local datacenter
- replicas should be alive according to the failure detector
- write to min(2, number of qualifying candiates above) batchlog nodes
Other notes:
- need to add an optimization to flush that if the memtable is older than
gc_g_s, we should do an extra removeDeleted pass to avoid writing tombstones
that are already obsolete. this is crucial to keeping batchlog from becoming a
new source of compaction pain.
- need acknowledged_by_batchlog boolean for TimedOutException; if we timeout
during the BL write (which is always effective CL.ONE) then we should return
acknowledged_by_batchlog=false, acknowledged_by=0; if we timeout *after* the BL
write, we should return acknowledged_by_batchlog=true, acknowledged_by=-1
> add atomic_batch_mutate method
> ------------------------------
>
> Key: CASSANDRA-4542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4542
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
> Reporter: Jonathan Ellis
> Assignee: Aleksey Yeschenko
> Fix For: 1.2
>
>
> atomic_batch_mutate will have the same parameters as batch_mutate, but will
> write to the batchlog before attempting distribution to the batch rows'
> replicas.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
