[
https://issues.apache.org/jira/browse/CASSANDRA-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14595491#comment-14595491
]
Sylvain Lebresne commented on CASSANDRA-9621:
---------------------------------------------
I don't particularly care if we make CASSANDRA-5839 opt-in or not, but I do
think this issue shouldn't weight much in that decision. As Markus said, this
would still hurt people enabling it and it's not gonna be clear at all that
opting-in for CASSANDRA-5839 buys you into this.
Anyway, the patch is very simple and I don't think it's a big deal if we want
to undo it later so I'm not too fussed about this issue but I'm personally +1
on Marcus' patch (though I'd add a comment pointing to this issue so we
remember why we're doing this).
> Repair of the SystemDistributed keyspace creates a non-trivial amount of
> memory pressure
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-9621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9621
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Marcus Eriksson
> Priority: Minor
> Fix For: 2.2.0 rc2
>
>
> When a repair without any particular option is triggered, the
> {{SystemDistributed}} keyspace is repaired for all range, and in particular
> the {{repair_history}} table. For every range, that table is written and
> flushed (as part of normal repair), meaning that every range triggers the
> creation of a new 1MB slab region (this also triggers quite a few compactions
> that also write and flush {{compaction_progress}} at every start and end).
> I don't know how much of a big deal this will be in practice, but I wonder if
> it's really useful to repair the {{repair_*}} tables by default so maybe we
> could exclude the SystemDistributed keyspace from default repairs and only
> repair it if asked explicitly?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
