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 <shya...@member.fsf.org>wrote: > >>>>> "Eric" == Eric Czech <e...@nextbigsound.com> 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 > >
