cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
Date Tue, 26 May 2015 16:30:20 GMT

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

Tyler Hobbs commented on CASSANDRA-9474:
----------------------------------------

This behavior existed before CASSANDRA-5897, just not for GossipingPropertyFileSnitch.  However,
I think you're right that allowing these kinds of changes by default is dangerous.  A config
file accidentally being changed while Cassandra is running could have pretty bad consequences.
 Outside of a development environment, I can't see how this is terribly useful.

[~brandon.williams] do you recall any scenarios where having reloading enabled is necessary?

> DC/Rack property changed on live system
> ---------------------------------------
>
>                 Key: CASSANDRA-9474
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9474
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Cassandra 2.1.5
>            Reporter: Marcus Olsson
>             Fix For: 2.1.x
>
>
> When using GossipingPropertyFileSnitch it is possible to change the data center and rack
of a live node by changing the cassandra-rackdc.properties file. Should this really be possible?
In the documentation at http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html
it's stated that you should ??Choose the name carefully; renaming a data center is not possible??,
but with this functionality it doesn't seem impossible(maybe a bit hard with changing replication
etc.).
> This functionality was introduced by CASSANDRA-5897 so I'm guessing there is some use
case for this?
> Personally I would want the DC/rack settings to be as restricted as the cluster name,
otherwise if a node could just join another data center without removing it's local information
couldn't it mess up the token ranges? And suddenly the old data center/rack would loose 1
replica of all the data that the node contains.



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

Mime
View raw message