incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Black...@b3k.us>
Subject Re: Seeds, autobootstrap nodes, and replication factor
Date Fri, 04 Jun 2010 17:46:35 GMT
On Fri, Jun 4, 2010 at 10:36 AM, Philip Stanhope <pstanhope@wimba.com> wrote:
>
> Here's the scenario: would like R = N where N is the number of nodes. Let's say 8.
>
> 1. Create first node, modify storage-conf.xml and change the <Seed/> to be the
ip of the node. Change replication factor to 8 for CF of interest. Start the puppy up.
>

RF is per Keyspace, not per CF.

> 2. Create 2nd node, modify storage-confg.xml and change <AutoBootstrap/> to true
and let it know the first seed. Ensure replication factor is 8 for the CF of interest. Start
the puppy up.
>

If you do it this way be aware token automatic assignment may not do
what you want.  It _probably_ will, since 8 is a power of 2, but be
aware.

> 3. Create 3rd node.
>
> Q1: Should the node1 and node2 be listed as seeds? Or only node1?
>

Doesn't matter.  Seeds are only used as a discovery mechanism.  One is
sufficient.

> 4. Create 4th node. Same question as before.
>
> Q2: Same question as before ... should the list of seeds grow as the cluster grows? Alternative
phrasing ... what is the relationship between Seed and AutoBootstrap, i.e. can a Seed node
in fact be a node that was autobootstrapped? Is this considered best practice?
>

Once a node is bootstrapped, auto or otherwise, that's it.  It is now
just another node in the cluster.  How it got that way is not
relevant.

> At this point we've got 4 nodes in the cluster ... I've gotten this far with no problems,
loaded with tons of data and compared performance with various replication factors. Seeing
faster reads from any particular node (as expected) when the ReplicationFactor is equal to
the number of nodes in the cluster. Have compared lots of single update/creates as well as
batch_mutate (which is very fast for bootstrapping the CFs -- highly recommended).
>
> And also seeing varying performance on reads (fast, and as expected) when ReplicationFactor
< N.
>
> Q3: What, if any issue, is there when R > N?
>

Not recommended.

> This is the situation as you're bringing up nodes in the cluster. And when you take down
a node (intentionally or as a failure).
>
> I know one consideration is that if R >= N ... and CF data grows ever bigger ... there
will be a hit as the node is created.
>
> Q4: If you know that you're never going to have more than 40 (MaxExpectedClusterNodes)
in your cluster ... is it safe to set R >= MaxExpectedClusterNodes?
>

Setting it higher is not going to help you.  It is also unclear to me
how having a cluster that large with an RF that high is going to
behave.  Read repair (which happens on every call) is going to be
_brutal_.

> Q5: If you set R = MaxExpectedClusterNodes ... and you end up servicing a node .... and
bringing up an alternate node in its place ... thus having R = N at all times ... and then
you bring up the N+1 node ... will it start to receive the data that it missed while it was
down?
>

This is the Hinted Handoff mechanism.


b

Mime
View raw message