cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Roth (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-13066) Fast repair with materialized views
Date Wed, 21 Dec 2016 08:43:58 GMT
Benjamin Roth created CASSANDRA-13066:
-----------------------------------------

             Summary: Fast repair with materialized views
                 Key: CASSANDRA-13066
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13066
             Project: Cassandra
          Issue Type: Improvement
            Reporter: Benjamin Roth


I propose adding a configuration option to send streams of tables with MVs not through the
regular write path.
This may be either a global option or better a CF option.

Background:
A repair of a CF with an MV that is much out of sync creates many streams. These streams all
go through the regular write path to assert local consistency of the MV. This again causes
a read before write for every single mutation which again puts a lot of pressure on the node
- much more than simply streaming the SSTable down.
In some cases this can be avoided. Instead of only repairing the base table, all base + mv
tables would have to be repaired. But this can break eventual consistency between base table
and MV. The proposed behaviour is always safe, when having append-only MVs. It also works
when using CL_QUORUM writes but it cannot be absolutely guaranteed, that a quorum write is
applied atomically, so this can also lead to inconsistencies, if a quorum write is started
but one node dies in the middle of a request.

So, this proposal can help a lot in some situations but also can break consistency in others.
That's why it should be left upon the operator if that behaviour is appropriate for individual
use cases.

This issue came up here:
https://issues.apache.org/jira/browse/CASSANDRA-12888?focusedCommentId=15736599&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15736599



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

Mime
View raw message