cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Olsson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13079) Repair doesn't work after several replication factor changes
Date Wed, 28 Dec 2016 17:40:58 GMT

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

Marcus Olsson commented on CASSANDRA-13079:
-------------------------------------------

Good to hear that --full did the trick.

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.

In the scenario for adding a new data center I believe the recommended approach is to disable
auto bootstrap and instead change the replication factor when the full data center is up and
running. And then run "nodetool rebuild" to stream over the data from an existing data center.
In that scenario it could be large amounts of data that would get marked as unrepaired and
would have to be repaired again causing unnecessary load on the cluster.

Another scenario is reducing the replication factor, in that case I don't think there would
be a need to alter the repair state since there should only be less replicas, but to me it
feels like this scenario would be easier to cover than the multi-dc one.

Unless I'm missing something with the multi-dc scenario I'd say this would need to be implemented
as an optional feature to avoid complexity(both operational and in code), but I'm not sure
how this would be done or how feasible it is currently. Perhaps by adding some metadata to
the schema altering statements?

> 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)

Mime
View raw message