cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10243) Warn or fail when changing cluster topology live
Date Fri, 20 Nov 2015 21:32:11 GMT


Paulo Motta commented on CASSANDRA-10243:

Finished second part of review and don't have much to add besides the previous comments. Very
nice and comprehensive dtest and unit test suite, congratulations!

I wasn't very familiar with PropertyFileSnitch and YamlPropertyFileSnitch so took a bit longer
to review those, specially the default rack/dc thing. I don't see much point in keeping PropertyFileSnitch
around (and having to maintain it), given you can achieve the same, and even more, in a much
simpler way with GossipingPropertyFileSnitch, so created CASSANDRA-10745 to deprecate the

While this is very well tested and CASSANDRA-10242 and CASSANDRA-9474 don't make much sense
without this patch this is quite a bit of code to add in the end of 2.1, so I'll leave to
the committer to decide if this should go into 2.1, but I guess it should be OK.

Addressing your previous comments:

bq. my preference would be to leave existing code unchanged, especially if this goes to 2.1,
but I am not opposed to simplifying the new liveliness check for the snitch to what you suggested


bq. I don't see why wait for up to 60 seconds before reloading a config file, 5 seconds is
a pretty long time and it should not have any adverse impact.

this file is rarely ever changed, and now even less, so 60 seconds is more than enough, but
if lowering makes testing easier I guess it should be fine

bq. maybe we should never allow chaning dc/rack for GPFS, or remove the config reload altogether
as suggested in 

+1, we should keep GPFS as simple as possible, and I don't see much sense in reloading only
prefer_local. You can maybe just reuse the [patch|]
from CASSANDRA-9474 which is ready.

bq. Should we add a JVM property to override the liveliness checks, just as a safety measure
in case someone has a legitimate reason to change rack/dc of a live node?

I don't see a legitimate reason to change the rack/dc of a live node and restarting the node
in this case shouldn't be a big deal, so better avoid adding new properties IMO.

Good job!

> Warn or fail when changing cluster topology live
> ------------------------------------------------
>                 Key: CASSANDRA-10243
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Jonathan Ellis
>            Assignee: Stefania
>            Priority: Critical
>             Fix For: 2.1.x
> Moving a node from one rack to another in the snitch, while it is alive, is almost always
the wrong thing to do.

This message was sent by Atlassian JIRA

View raw message