cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulo Motta <pauloricard...@gmail.com>
Subject Re: CASSANDRA-9143
Date Wed, 24 Aug 2016 23:09:37 GMT
Thanks for sharing this! I added some comments/suggestions on the ticket
for those interested.

On a side note, it's still not clear if we should do the discussion here on
the dev-list or just call attention for a particular issue/ticket and then
continue discussion on JIRA, but I find the latter more appropriate to
avoid spamming those not interested, and only update here if there are new
developments in the ticket direction.

2016-08-24 18:35 GMT-03:00 Blake Eggleston <beggleston@apple.com>:

> Hi everyone,
>
> I just posted a proposed solution to some issues with incremental repair
> in CASSANDRA-9143. The solution involves non-trivial changes to the way
> incremental repair works, so I’m giving it a shout out on the dev list in
> the spirit of increasing the flow of information here.
>
> Summary of problem:
>
> Anticompaction excludes sstables that have been, or are, compacting.
> Anticompactions can also fail on a single machine due to any number of
> reasons. In either of these scenarios, a potentially large amount of data
> will be marked as unrepaired on one machine that’s marked as repaired on
> the others. During the next incremental repair, this potentially large
> amount of data will be unnecessarily streamed out to the other nodes,
> because it won’t be in their unrepaired data.
>
> Proposed solution:
>
> Add a ‘pending repair’ bucket to the existing repaired and unrepaired
> sstable buckets. We do the anticompaction up front, but put the
> anticompacted data into the pending bucket. From here, the repair proceeds
> normally against the pending sstables, with the streamed sstables also
> going into the pending buckets. Once all nodes have completed streaming,
> the pending sstables are moved into the repaired bucket, or back into
> unrepaired if there’s a failure.
>
> - Blake

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message