cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9474) DC/Rack property changed on live system
Date Thu, 12 Nov 2015 22:49:11 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Mime
View raw message