[
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: [email protected]
For additional commands, e-mail: [email protected]
