Ec2Snitch & Other snitches...

[Sasha Dolgy <sd...@gmail.com>]

Hi Everyone,

Can the Ec2Snitch be enabled by adjusting the parameter in the
cassandra.yaml and restarting the node?

More, I suppose the question I'm after is, can the snitch method be
adjusted adhoc (with node restart) or once it's changed from
SimpleSnitch to Ec2Snitch that's it?  What influence does one node
have over the Gossiper?  If i'm not happy with the Ec2Snitch, I want
to change to PropertyFileSnitch ... but if I have 8 nodes at the
moment. ... i don't want to create additional headaches...

-- 
Sasha Dolgy
sasha.dolgy@gmail.com

Re: Ec2Snitch & Other snitches...

[Sasha Dolgy <sd...@gmail.com>]

Thanks for the good response.

my thought was as aws becomes more and more expensive (no option to swap out
small cheap disks for larger cheap disks...) i'll need to switch to
dedicated hardware and the topology will change.  didnt want to back myself
into a corner early on when the amount of data is still manageable.

-sd
On Mar 22, 2011 5:05 PM, "Robert Coli" <rc...@digg.com> wrote:
> On Tue, Mar 22, 2011 at 7:19 AM, Sasha Dolgy <sd...@gmail.com> wrote:
>> More, I suppose the question I'm after is, can the snitch method be
>> adjusted adhoc (with node restart) or once it's changed from
>> SimpleSnitch to Ec2Snitch that's it?
>
> You can change Snitches on a cluster with data on it, as long as you
> are very careful about what you are doing and you are in a particular
> case which you are probably not in if you want to change your Snitch.
>
> The snitch meaningfully determines replica placement strategy, and in
> general when changing snitches you need the replica placement strategy
> to stay exactly the same. Unfortunately the point of changing a snitch
> is usually.. changing your replica placement strategy. Simplest case
> is if the replica placement strategy actually stays the same, like for
> example when Digg replaced its custom version of the
> PropertyFileSnitch with SimpleSnitch in prep for going single-DC,
> because we weren't actually using the functionality of PFS. In that
> case, I simply generated a set of input which hashed correctly such
> that I had one piece of input per node. I then verified the topology
> based on this input before and after changing my snitch, and got the
> same results both times, confirming that my change of the Snitch was a
> no-op.
>
> A less simple, but still tractable case is if the topology changes
> such that one or more replicas is different but at least one is still
> the same. In this case, repair would be likely to repair.. most.. of
> your data. But honestly if you have to change strategy that much (and
> are not running IP-partitioned counts, which make this operation much
> more difficult) you probably just want to dump and reload your data
> into a new cluster which has the topology and snitch you want.
>
> =Rob

Re: Ec2Snitch & Other snitches...

[Robert Coli <rc...@digg.com>]

On Tue, Mar 22, 2011 at 7:19 AM, Sasha Dolgy <sd...@gmail.com> wrote:
> More, I suppose the question I'm after is, can the snitch method be
> adjusted adhoc (with node restart) or once it's changed from
> SimpleSnitch to Ec2Snitch that's it?

You can change Snitches on a cluster with data on it, as long as you
are very careful about what you are doing and you are in a particular
case which you are probably not in if you want to change your Snitch.

The snitch meaningfully determines replica placement strategy, and in
general when changing snitches you need the replica placement strategy
to stay exactly the same. Unfortunately the point of changing a snitch
is usually.. changing your replica placement strategy. Simplest case
is if the replica placement strategy actually stays the same, like for
example when Digg replaced its custom version of the
PropertyFileSnitch with SimpleSnitch in prep for going single-DC,
because we weren't actually using the functionality of PFS. In that
case, I simply generated a set of input which hashed correctly such
that I had one piece of input per node. I then verified the topology
based on this input before and after changing my snitch, and got the
same results both times, confirming that my change of the Snitch was a
no-op.

A less simple, but still tractable case is if the topology changes
such that one or more replicas is different but at least one is still
the same. In this case, repair would be likely to repair.. most.. of
your data. But honestly if you have to change strategy that much (and
are not running IP-partitioned counts, which make this operation much
more difficult) you probably just want to dump and reload your data
into a new cluster which has the topology and snitch you want.

=Rob