[
https://issues.apache.org/jira/browse/CASSANDRA-10446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15648625#comment-15648625
]
Paulo Motta commented on CASSANDRA-10446:
-----------------------------------------
bq. doesn't CASSANDRA-6503 handle this issue?
Good point! I didn't recall this so this is not as bad as I though initially
but there is still at least one hairy scenario where things could go wrong:
{noformat}
A: unrepaired={1} repaired={}
B: unrepaired={2} repaired={}
C: unrepaired={3} repaired={}
{noformat}
During incremental repair, A sends key 1 to B and dies. B and C stream
successful. At the end of the failed repair session, things will look like:
{noformat}
A: unrepaired={1} repaired={}
B: unrepaired={2} repaired={1, 2, 3}
C: unrepaired={3} repaired={2, 3}
{noformat}
If A dies permanently before next repair, key 1 will never be incrementally
repaired between B and C. Likewise, if C dies, A will never get key 3 from B
via incremental repair. Maybe this is such an edge case it that wouldn't
justify a change per se, but if we defer setting repairedAt of streamed
sstables to anti-compaction phase then we could make this slightly more correct
while supporting session-based --force repair without adding a new repairedAt
field to {{SyncRequest}}.
> Run repair with down replicas
> -----------------------------
>
> Key: CASSANDRA-10446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10446
> Project: Cassandra
> Issue Type: Improvement
> Reporter: sankalp kohli
> Assignee: Blake Eggleston
> Priority: Minor
> Fix For: 4.0
>
>
> We should have an option of running repair when replicas are down. We can
> call it -force.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
