[
https://issues.apache.org/jira/browse/CASSANDRA-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593607#comment-14593607
]
Sylvain Lebresne commented on CASSANDRA-9621:
---------------------------------------------
Yes, though that's not only a problem for sequential repairs. That is, I could
agree that the underlying problem is that we flush for every range, but
CASSANDRA-9491 only has a (partial) solution for sequential repair currently.
And since a proper solution to that in all case (including parallel repairs) is
probably not coming before the release of 2.2, I'd suggest implementing this to
avoid surprise for people upgrading to 2.2. Not that I feel terribly strongly,
just feels the safer option to me.
> 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)
