[jira] [Commented] (CASSANDRA-13079) Repair doesn't work after several replication factor changes

["Jeff Jirsa (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-13079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15793609#comment-15793609 ] 

Jeff Jirsa commented on CASSANDRA-13079:
----------------------------------------

{quote}And this rise a question - shouldn't replication factor change also reset repair state for this keyspace?{quote}

If replication factor is increased, it seems like it should, in fact, reset the repair state for that keyspace. The fact that we don't is probably a bug.  

{quote}
I think it would be a good idea for this type of scenario to change the repair state during replication altering, but I'm not sure if that's always the case.
{quote}

The principle of least astonishment applies here - a user running repair should expect all data to be repaired, and a user who adds a new DC and then runs repair will see a lot of data streamed. That's not something that SHOULD surprise a user. They can work around it if they choose. The fact that incremental (default) repair doesn't do anything if you change from rf=1 to rf=2 is more surprising and dangerous than extra streaming, so I imagine we should consider that more important.



> Repair doesn't work after several replication factor changes
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-13079
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13079
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Debian 
>            Reporter: Vladimir Yudovin
>            Priority: Critical
>
> Scenario:
> Start two nodes cluster.
> Create keyspace with rep.factor *one*:
> CREATE KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
> CREATE TABLE rep.data (str text PRIMARY KEY );
> INSERT INTO rep.data (str) VALUES ( 'qwerty');
> Run *nodetool flush* on all nodes. On one of them table files are created.
> Change replication factor to *two*:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 2};
> Run repair, then *nodetool flush* on all nodes. On all nodes table files are created.
> Change replication factor to *one*:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
> Then *nodetool cleanup*, only on initial node remained data files.
> Change replication factor to *two* again:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 2};
> Run repair, then *nodetool flush* on all nodes. No data files on second node (though expected, as after first repair/flush).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)