You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefan Podkowinski (JIRA)" <ji...@apache.org> on 2018/04/19 07:42:00 UTC

[jira] [Commented] (CASSANDRA-14400) Subrange repair doesn't always mark as repaired

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

Stefan Podkowinski commented on CASSANDRA-14400:
------------------------------------------------

The main reason for not marking sstables as repaired on sub-range repairs, was to avoid anti-compaction. Creating lots of small tables for small repair ranges will be inefficient and should also not be necessary, as incremental repairs should be run often enough to keep the unrepaired set reasonably small.

> Subrange repair doesn't always mark as repaired
> -----------------------------------------------
>
>                 Key: CASSANDRA-14400
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14400
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Kurt Greaves
>            Priority: Major
>
> So was just messing around with subrange repair on trunk and found that if I generated an SSTable with a single token and then tried to repair that SSTable using subrange repairs it wouldn't get marked as repaired.
>  
>  Before repair:
> {code:java}
> First token: -9223362383595311662 (derphead4471291)
> Last token: -9223362383595311662 (derphead4471291)
> Repaired at: 0
> Pending repair: 862395e0-4394-11e8-8f20-3b8ee110d005
> {code}
> Repair command:
> {code}
> ccm node1 nodetool "repair -st -9223362383595311663 -et -9223362383595311661 aoeu"
> [2018-04-19 05:44:42,806] Starting repair command #7 (c23f76c0-4394-11e8-8f20-3b8ee110d005), repairing keyspace aoeu with repair options (parallelism: parallel, primary range: false, incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 1, pull repair: false, force repair: false, optimise streams: false)
> [2018-04-19 05:44:42,843] Repair session c242d220-4394-11e8-8f20-3b8ee110d005 for range [(-9223362383595311663,-9223362383595311661]] finished (progress: 20%)
> [2018-04-19 05:44:43,139] Repair completed successfully
> [2018-04-19 05:44:43,140] Repair command #7 finished in 0 seconds
> {code}
> After repair SSTable hasn't changed and sstablemetadata outputs:
> {code}
> First token: -9223362383595311662 (derphead4471291)
> Last token: -9223362383595311662 (derphead4471291)
> Repaired at: 0
> Pending repair: 862395e0-4394-11e8-8f20-3b8ee110d005
> {code}
> And parent_repair_history states that the repair is complete/range was successful:
> {code}
> select * from system_distributed.parent_repair_history where parent_id=862395e0-4394-11e8-8f20-3b8ee110d005 ;
>  parent_id                            | columnfamily_names | exception_message | exception_stacktrace | finished_at                     | keyspace_name | options                                                                                                                                                                                                                                                                        | requested_ranges                                | started_at                      | successful_ranges
> --------------------------------------+--------------------+-------------------+----------------------+---------------------------------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------+---------------------------------+-------------------------------------------------
>  862395e0-4394-11e8-8f20-3b8ee110d005 |           {'aoeu'} |              null |                 null | 2018-04-19 05:43:14.578000+0000 |          aoeu | {'dataCenters': '', 'forceRepair': 'false', 'hosts': '', 'incremental': 'true', 'jobThreads': '1', 'optimiseStreams': 'false', 'parallelism': 'parallel', 'previewKind': 'NONE', 'primaryRange': 'false', 'pullRepair': 'false', 'sub_range_repair': 'true', 'trace': 'false'} | {'(-9223362383595311663,-9223362383595311661]'} | 2018-04-19 05:43:01.952000+0000 | {'(-9223362383595311663,-9223362383595311661]'}
> {code}
> Subrange repairs seem to work fine over large ranges and set {{Repaired at}} as expected, but I haven't figured out why it works for a large range versus a small range so far.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org