Kurt Greaves created CASSANDRA-14400:
----------------------------------------
Summary: 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
Fix For: 4.0
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]
