incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schuller <peter.schul...@infidyne.com>
Subject Re: how does cassandra pick its replicant peers?
Date Sat, 26 Mar 2011 22:13:59 GMT
> So if I understand correctly, the nodes getting the replica copies are predetermined,
based on the replication strategy.

Yes, pre-determined as a function of ring layout (which nodes have
which tokens), the replication factor, and the replication strategy.

> One thing is still a bit unclear.   So once a node establishes who its replicants are,
 are those "replicant nodes" always used?

To be clear, it's not that there is a primary node that internally
decides who is responsible for data. Rather, given the known rules for
determining which nodes are responsible for a given row key, any node
in the cluster is aware of that information.

In order to satisfy consistency levels during read and write
operations, requests are routed as appropriate to nodes that are
responsible for the row key.

So yes, the nodes responsible for a given row key are always used for
reads and writes to that row key.

>  In other words, given a RF=3, if the other two replica nodes go down, the "original"
node will not automatically pick 2 new nodes for its replica copies?

No. Actually moving data between nodes is done by ring management
operations; i.e., an operator deciding to decommission or move nodes.
Moving data is quite an expensive/significant operation and there is
no automatic mechanism to do this. The way to survive nodes going down
is to select an appropriate replication factor on the key space, and
select an appropriate consistency level for reads and writes.

(The only exception would be hinted hand-off when writing at CL.ANY
and hinted hand-off, but I'll leave that beyond the scope of this.)

-- 
/ Peter Schuller

Mime
View raw message