cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Knighton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10230) Remove coordinator batchlog from materialized views
Date Mon, 14 Sep 2015 16:01:46 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743721#comment-14743721
] 

Joel Knighton commented on CASSANDRA-10230:
-------------------------------------------

I'm just now finishing up some tests for this.

The test methodology is as follows:
1.  Tune the failure detector so that network partitions for the durations in the test will
not cause nodes to realize the cluster is partitioned.
2.  Partition the cluster so nodes 1 and 2 can communicate and nodes 3 and 4 can communicate.
3.  Write to the cluster at CL.ONE.
4. Heal the partition for three seconds, completely partition the cluster, perform a read
with a client connected to each node as coordinator, so that we know reads only come from
the coordinator.

Currently, testing shows that both hints and batchlogs successfully propagate all writes to
all replicas of the base tables without data loss. If both hints and batchlogs are disabled,
writes will never propagate (since read repair is impossible).

Graphs showing a rough estimate of propagation time (time from read on final replica - time
from read on first replica) will be uploaded shortly, along with a link to the Jepsen test.

> Remove coordinator batchlog from materialized views
> ---------------------------------------------------
>
>                 Key: CASSANDRA-10230
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10230
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: T Jake Luciani
>            Assignee: Joel Knighton
>             Fix For: 3.0.0 rc1
>
>
> We are considering removing or making optional the coordinator batchlog.  
> The batchlog primary serves as a way to quickly reach consistency between base and view
since we don't have any kind of read repair between base and view. But we do have repair so
as long as you don't lose nodes while writing at CL.ONE you will be eventually consistent.
> I've committed to the 3.0 branch a way to disable the coordinator with {{-Dcassandra.mv_disable_coordinator_batchlog=true}}
> The majority of the performance hit to throughput is currently the batchlog as shown
by this chart.
> http://cstar.datastax.com/graph?stats=f794245a-4d9d-11e5-9def-42010af0688f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=498.52&ymin=0&ymax=50142.4
> I'd like to have tests run with and without this flag to validate how quickly we achieve
quorum consistency without repair writing with CL.ONE.   Once we can see there is little/no
impact we can permanently remove the coordinator batchlog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message