You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2013/04/02 23:05:15 UTC

[jira] [Resolved] (CASSANDRA-5419) Employ column differencing (as done for read repairs) during node repairs

     [ https://issues.apache.org/jira/browse/CASSANDRA-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis resolved CASSANDRA-5419.
---------------------------------------

    Resolution: Duplicate

Detecting diffs smaller than a row is actually the hard part.  (See link.)
                
> Employ column differencing (as done for read repairs) during node repairs 
> --------------------------------------------------------------------------
>
>                 Key: CASSANDRA-5419
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5419
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.10
>         Environment: Production
>            Reporter: Ahmed Bashir
>              Labels: compaction, repair
>
> In particular for wide rows, the headroom required for node repairs can be substantial given that entire rows are streamed for any and all row hash discrepancies.
> This headroom must be sustained until compaction slowly compacts these newly streamed SSTables and reduces the overall load on each instance.
> The overall footprint of node repairs would be greatly reduced if we employed differencing at the column level and sent over row mutations, similar to what is done during read repair.  This is a great alternative for deployments wherein sending over entire rows rather than the deltas is not an option.  
> Since node repairs can now specify start and end tokens (i.e. subrange repairs), the additional computation can be broken down easily, and it's a welcome trade-off for significantly less streaming, compaction, and temporary headroom requirements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira