1. That is somewhat disappointing. Wish the redundancy of write on the coordinator node could have been avoided somehow.
Does the write on the coordinator node (incase it is not part of the N replica nodes for that key) get deleted before response of the write is returned back to the client ?

On Tue, Feb 15, 2011 at 4:40 PM, Matthew Dennis <> wrote:
1. Yes, the coordinator node propagates requests to the correct nodes.

2. most (all?) higher level clients (pycassa, hector, etc) load balance for you.  In general your client and/or the caller of the client needs to catch exceptions and retry.  If you're using RRDNS and some of the nodes are temporarily down, you wouldn't bother to update DNS; your client would just route to some other node that is up after noticing the first node is down.

In general you don't want a load balancer in front of the nodes as the load balancer itself becomes a SPOF as well as a performance bottleneck (not to mention the extra cost and complexity).  By far the most common setup is to have the clients load balance for you, coupled with retry logic in your application.

On Tue, Feb 15, 2011 at 2:45 PM, A J <> wrote:
>From my reading it seems like the node that the client connects to becomes the coordinator node. Questions:

1. Is it true that the write first happens on the coordinator node and then the coordinator node propagates it to the right primary node and the replicas ? In other words if I have a 2G write, would the 2G be transferred first to the coordinator node or is it just a witness and just waits for the transfer to happen directly between the client and required right nodes ?

2. How do you load-balance between the different nodes to give all equal chance to become co-ordinator node ? Does the client need a sort of round-robin DNS balancer ? if so, what if some of the nodes drop off. How to inform the DNS balancer  ?
Or do I need a proper load balancer in front that looks at the traffic on each node and accordingly selects a co-ordinator node ? What is more pervalent ?