cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Czech <>
Subject Re: unwanted node discovery
Date Sun, 02 Oct 2011 22:45:10 GMT
Yea that's not a mapping I'd like to maintain either -- as an experiment, I
copied production sstables to the analysis cluster and ran brisk/cassandra
without specifying an initial token (after deleting the LocationInfo* files
and renaming the cluster).  As far as I can tell, everything is running
normally but I'm not sure how the cluster chose tokens for the nodes given
that I didn't specify them after just dropping the raw sstables in.  I can
still read data as usual from the column families that were copied but I'm
not sure how not specifying the tokens affects everything.  Is some of my
data just unreachable now because the tokens weren't manually defined?  This
doesn't appear to be the case but is this something you have tried too or do
you understand the storage / topology logic well enough to know that this
isn't a viable strategy?

On Sun, Oct 2, 2011 at 4:14 PM, Shyamal Prasad <>wrote:

> >>>>> "Eric" == Eric Czech <> writes:
>     Eric> Hi Shyamal, I was using the same cluster name but since
>    Eric> writing that first email, I've already had success bringing up
>    Eric> nodes in the analysis cluster with a different cluster name
>    Eric> after deleting the LocationInfo* tables.
>    Eric> How have you been setting the tokens in the copied version of
>    Eric> the cluster?  Are you just mapping them one-to-one on the
>    Eric> original cluster?
> Yep. It's brittle but it works. It's brittle because if the production
> cluster topology changes I have some work to do (since the copied
> SSTables will now not match the static mapping until I manually update
> it).
> I've yet to find a simpler way to do this (the LocationInfo CF stores
> (token, inetaddress) pairs, and those simply don't automagically
> transfer to a backup cluster).
> /Shyamal

View raw message