[
https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068104#comment-16068104
]
Mikael Valot commented on CASSANDRA-5836:
-----------------------------------------
Same here, we had 3 DSE 5.1 nodes and created 3 new nodes as seeds, with a
replication factor = 3
Everything was looking good until our users noticed that some data was missing,
a few hours before an important client demo.
It was fortunate that it was not a production environment and that we had
another environment available for the demo.
We observed during the data loss that some partitions were allocated to the 3
new nodes, which explains why the data was not accessible anymore.
We managed to recover the data by stopping one of the new nodes, and by running
nodetool removenode followed by nodetool repair.
Cassandra subsequently managed to copy the data from the old nodes to the 2 new
ones.
Cassandra should either prevent the user from starting the new nodes when they
are setup as seeds, or have some mechanism to prevent any loss of data.
IMHO this ticket should be reopened.
> Seed nodes should be able to bootstrap without manual intervention
> ------------------------------------------------------------------
>
> Key: CASSANDRA-5836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5836
> Project: Cassandra
> Issue Type: Bug
> Reporter: Bill Hathaway
> Priority: Minor
>
> The current logic doesn't allow a seed node to be bootstrapped. If a user
> wants to bootstrap a node configured as a seed (for example to replace a seed
> node via replace_token), they first need to remove the node's own IP from the
> seed list, and then start the bootstrap process. This seems like an
> unnecessary step since a node never uses itself as a seed.
> I think it would be a better experience if the logic was changed to allow a
> seed node to bootstrap without manual intervention when there are other seed
> nodes up in a ring.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
