[
https://issues.apache.org/jira/browse/CASSANDRA-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659416#comment-14659416
]
Stefania commented on CASSANDRA-5220:
-------------------------------------
Thanks, I made a couple more really tiny changes
[here|https://github.com/stef1927/cassandra/commit/dbd5c88c6f89ff303f4fece9bb8c5ffa6c3825a1].
The TODO comment above was misplaced sorry, I meant it for {{MerkleTrees}}.
You're quite right that we don't need to change the existing trunk behavior.
About _repair_history_, I verified it would result in an exception when
upgrading from 2.2 with some sstables already on disk. Although I believe we
could ask people to wipe this data on a major upgrade, I don't see why
inconvenience people and so I went ahead and reverted the old format and
inserted one line per rage, see commit
[here|https://github.com/stef1927/cassandra/commit/92bd923a8b2d9976dc711f1b7007d25db30d06f9].
Thanks for spotting this.
If you confirm these final changes are OK, then I am +1 to commit once CI
completes.
[~jbellis] I assume we want this on 3.0? If so I ported the patch to
_cassandra-3.0_ [here|https://github.com/stef1927/cassandra/commits/5220-3.0].
It is identical to the [trunk
patch|https://github.com/stef1927/cassandra/commits/5220] as it applied with no
conflicts. You can pick whichever you need depending on where you want to
commit to and discard the other one.
CI results for trunk will appear here:
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-5220-testall/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-5220-dtest/
CI results for 3.0 are instead here:
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-5220-3.0-testall/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-5220-3.0-dtest/
> Repair improvements when using vnodes
> -------------------------------------
>
> Key: CASSANDRA-5220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5220
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.2.0 beta 1
> Reporter: Brandon Williams
> Assignee: Marcus Olsson
> Labels: performance, repair
> Attachments: 5220-yourkit.png, 5220-yourkit.tar.bz2,
> cassandra-3.0-5220-1.patch, cassandra-3.0-5220-2.patch,
> cassandra-3.0-5220.patch
>
>
> Currently when using vnodes, repair takes much longer to complete than
> without them. This appears at least in part because it's using a session per
> range and processing them sequentially. This generates a lot of log spam
> with vnodes, and while being gentler and lighter on hard disk deployments,
> ssd-based deployments would often prefer that repair be as fast as possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
