[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018397#comment-15018397 ] Paulo Motta commented on CASSANDRA-9474: Thanks for the patches. I submitted a [cassandra-dtest PR|https://github.com/riptano/cassandra-dtest/pull/678] and cassci test runs. Since this is only a startup check, and 2.1.12 wasn't released yet with the rack startup check (CASSANDRA-10243) I think it's better to include this patch on 2.1 for completeness, so I backported it to 2.1. We should also include it on 3.0.1 and 3.1 since the "ignore_rack" flag was removed on 2.2/3.0, but is present on 2.1, so removing the flag would be a regression. Below are branches and test results: ||2.1||2.2||3.0||3.1||trunk|| |[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-9474]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-9474]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-9474]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.1...pauloricardomg:3.1-9474]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-9474]| |[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-9474-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-9474-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-9474-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.1-9474-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-9474-testall/lastCompletedBuild/testReport/]| |[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-9474-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-9474-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-9474-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.1-9474-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-9474-dtest/lastCompletedBuild/testReport/]| Will mark as ready to commit once tests are OK. > DC/Rack property changed on live system > --- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 2.1.x > > Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010631#comment-15010631 ] Marcus Olsson commented on CASSANDRA-9474: -- Agreed, I will remove my parts regarding the Snitch reload. My patch will only contain the startup checks and re-adding of the cassandra.ignore_rack flag. :) > DC/Rack property changed on live system > --- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 2.1.x > > Attachments: cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010654#comment-15010654 ] Stefania commented on CASSANDRA-9474: - Thanks, 10243 should be Patch Available in the next few days. > DC/Rack property changed on live system > --- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 2.1.x > > Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15008640#comment-15008640 ] Marcus Olsson commented on CASSANDRA-9474: -- [~pauloricardomg] In the 2.2 [NEWS.txt|https://github.com/apache/cassandra/commit/7cab3272455bdd16b639c510416ae339a8613414#diff-4302f2407249672d7845cd58027ff6e9R16] it seems like the part with cassandra.ignore_rack was removed as well, so it might have been done on purpose? Ping [~iamaleksey] I'll add the flags and checks to CassandraDaemon, will probably have a patch set up soon. :) > DC/Rack property changed on live system > --- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 2.1.x > > Attachments: cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15008522#comment-15008522 ] Marcus Olsson commented on CASSANDRA-9474: -- I've started the implementation towards 2.2 and done a dtest for it. I have just one question regarding the cassandra.ignore_dc flag, in the 2.2 branch I can't seem to find the cassandra.ignore_rack flag [here|https://github.com/apache/cassandra/commit/7cab3272455bdd16b639c510416ae339a8613414], should I be consistent and not add it? > DC/Rack property changed on live system > --- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 2.1.x > > Attachments: cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[
https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15008596#comment-15008596
]
Paulo Motta commented on CASSANDRA-9474:
[~molsson] Thanks for spotting this. It seems the flag was removed during the
[up-merge|https://github.com/apache/cassandra/commit/7cab3272455bdd16b639c510416ae339a8613414#diff-ce3f6856b405c96859d9a50d9977e0b9]
of CASSANDRA-10242 to 2.2, since there was also a minor change in the
implementation, where the check was moved from SystemKeyspace to
CassandraDaemon (which is a more adequate place for this check anyway, so you
should also place the dc check there).
I believe it was an oversight, so could you please add
{{cassandra.ignore_rack}} flag back (in addition to the new
{{cassandra.ignore_dc}} flag)? since it's already documented on 2.1 NEWS.txt,
we should still keep both flags. Also could you mention these flags in the
error messages? So if somebody Knows What Is Doing©, then it will find out
about the flags.
> DC/Rack property changed on live system
> ---
>
> Key: CASSANDRA-9474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9474
> Project: Cassandra
> Issue Type: Improvement
> Environment: Cassandra 2.1.5
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
> Fix For: 2.1.x
>
> Attachments: cassandra-2.1-9474.patch,
> cassandra-2.1-dc_rack_healthcheck.patch
>
>
> 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009972#comment-15009972 ] Stefania commented on CASSANDRA-9474: - I think there is a fair bit of duplication with CASSANDRA-10243, which I am currently working on. Here were are blocking config reload if the rack or dc of a live node changes, for all snitches supporting config reload. > DC/Rack property changed on live system > --- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 2.1.x > > Attachments: cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[
https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003120#comment-15003120
]
Paulo Motta commented on CASSANDRA-9474:
Thanks for the patch [~molsson]! In fact, the only reason I see for
PropertyFileSnitch to be reloadable is to add new nodes, but this is not
necessary on GossipingPropertyFileSnitch as you mentioned.
The patch looks good. We're towards the end of 2.1 development so we're
avoiding adding changes at this stage, could you update/rebase your patch to
2.2 and 3.0? A few remarks:
* Register the {{ReconnectableSnitchHelper}} only if prefer_local=true
** I thought we could do the same with broadcasting the INTERNAL_IP, but better
to always broadcast in case this is needed somewhere else.
* As you noted, CASSANDRA-10242 already added the check to the rack, so if you
could add the dc check on the top of that it would be nice. Since the
{{cassandra.ignore_rack}} was introduced and documented, then I think we should
add an additional property {{cassandra.ignore_dc}} to be consistent.
** Please add a note to {{NEWS.txt}} (on 2.2.4) similar to
[this|https://github.com/apache/cassandra/blob/29ff1f2ac2a3da16f75ce87555df8f6014c8303e/NEWS.txt#L21]
of CASSANDRA-10242.
If you have access to a cassandra-dtest environment, it would be nice if you
could create a variant of [this
dtest|https://github.com/carlyeks/cassandra-dtest/blob/47ceb7995c6a4f9599c8a257f995c75ec518b241/replication_test.py#L460]
to check if the startup fails when the DC is changed. Otherwise I can create
it before accepting the patch.
> DC/Rack property changed on live system
> ---
>
> Key: CASSANDRA-9474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9474
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.1.5
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
> Fix For: 2.1.x
>
> Attachments: cassandra-2.1-9474.patch,
> cassandra-2.1-dc_rack_healthcheck.patch
>
>
> 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563176#comment-14563176 ] Brandon Williams commented on CASSANDRA-9474: - PFS had it first, so GPFS just added it to have feature parity. 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14560563#comment-14560563 ] Marcus Olsson commented on CASSANDRA-9474: -- Yes, that's true, but for e.g. PropertyFileSnitch this could have some other benefits like getting the DC/rack information for new nodes. One thing that's good about the reloading is that you get some kind of negative response almost directly after changing the configuration, which I think is better than getting it whenever that Cassandra instance is restarted since that would be harder to trace back to the faulty configuration. Or better yet, to have DC and rack configuration be a part of the sanity check at startup, which would make switching DC/rack information harder, but still not impossible(update system.local). 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559127#comment-14559127 ] Philip Thompson commented on CASSANDRA-9474: [~thobbs], you reviewed CASSANDRA-5897, what are your thoughts on this? 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)
[jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
