You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Thomas van Neerijnen <to...@bossastudios.com> on 2012/10/19 14:49:55 UTC

unexpected behaviour on seed nodes when using -Dcassandra.replace_token

Hi all

I recently tried to replace a dead node using
-Dcassandra.replace_token=<token>, which so far has been good to me.
However on one of my nodes this option was ignored and the node simply
picked a different token to live at and started up there.

It was a foolish mistake on my part because it was set as a seed node,
which results in this error in the log file:
INFO [main] 2012-10-19 12:41:00,886 StorageService.java (line 518) This
node will not auto bootstrap because it is configured to be
 a seed node.
but it seems a little scary that this would mean it'll just ignore the fact
that you want a replace a token and put itself somewhere else in the
cluster. Surely it should behave similarly to trying to replace a live node
by throwing some kind of exception?

Re: unexpected behaviour on seed nodes when using -Dcassandra.replace_token

Posted by Edward Capriolo <ed...@gmail.com>.
Yes. That would be a good jira if it is not already listed. If node is
a seed node autobootstrap and replicate_token settings should trigger
a fatal non-start because your giving c* conflicting directions.

Edward

On Fri, Oct 19, 2012 at 8:49 AM, Thomas van Neerijnen
<to...@bossastudios.com> wrote:
> Hi all
>
> I recently tried to replace a dead node using
> -Dcassandra.replace_token=<token>, which so far has been good to me.
> However on one of my nodes this option was ignored and the node simply
> picked a different token to live at and started up there.
>
> It was a foolish mistake on my part because it was set as a seed node, which
> results in this error in the log file:
> INFO [main] 2012-10-19 12:41:00,886 StorageService.java (line 518) This node
> will not auto bootstrap because it is configured to be
>  a seed node.
> but it seems a little scary that this would mean it'll just ignore the fact
> that you want a replace a token and put itself somewhere else in the
> cluster. Surely it should behave similarly to trying to replace a live node
> by throwing some kind of exception?