[
https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290933#comment-13290933
]
Eric Evans commented on CASSANDRA-2356:
---------------------------------------
{quote}
1) node A has token X
2) node A dies and the OS crashes
3) node A is replaced by node B, also at token X (say by restoring a full
snapshot)
4) node A is rebooted (say as part of RMA process)
5) cluster accepts node A as the rightful owner of token X, because it has a
later generation number by virtue of having been more recently started
6) you have a two nodes which contain the same but desychronized dataset, at
the same token, and no straightforward way to unify them
{quote}
The best way to deal with a situation like this is to make Cassandra do the
Right Thing. Barring that, you could hack the init script to check for this
condition and make startup a noop (or error), which would work even if someone
had overridden the start policy.
For what it's worth, I remember running across code recently that I think would
safeguard against this; Is this a failure scenario that you've tested against
recent versions?
bq. Are there any circumstances where auto-starting, esp. on packaged install
or upgrade, is actually desirable?
This is considered configuration, and with any configuration all you can do is
provide a reasonable default, something that will work for most of the people,
most of the time. Starting a service by default is generally considered The
Way[*] on Debian systems, (and hence the least surprising choice for our Debian
package).
[*] The oft stated reason being that if the user didn't want the service
running, they wouldn't have installed it.
> make the debian package never start by default
> ----------------------------------------------
>
> Key: CASSANDRA-2356
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2356
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
> Reporter: Jeremy Hanna
> Priority: Minor
> Labels: debian, packaging
> Attachments: 2356.txt
>
>
> Currently the debian package that installs cassandra starts cassandra by
> default. It sounds like that is a standard debian packaging convention.
> However, if you want to bootstrap a new node and want to configure it before
> it creates any sort of state information, it's a pain. I would think that
> the common use case would be to have it install all of the init scripts and
> such but *not* have it start up by default. That way an admin can configure
> cassandra with seed, token, host, etc. information and then start it. That
> makes it easier to programmatically do this as well - have chef/puppet
> install cassandra, do some configuration, then do the service start.
> With the current setup, it sounds like cassandra creates state on startup
> that has to be cleaned before a new configuration can take effect. So the
> process of installing turns into:
> * install debian package
> * shutdown cassandra
> * clean out state (data/log dirs)
> * configure cassandra
> * start cassandra
> That seems suboptimal for the default case, especially when trying to
> automate new nodes being bootstrapped.
> Another case might be when a downed node comes back up and starts by default
> and tries to claim a token that has already been claimed by another newly
> bootstrapped node. Rob is more familiar with that case so I'll let him
> explain it in the comments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
