37

I'm a little confused about Cassandra seed nodes and how clients are meant to connect to the cluster. I can't seem to find this bit of information in the documentation.

Do the clients only contain a list of the seed node and each node delegates a new host for the client to connect to? Are seed nodes only really for node to node discovery, rather than a special node for clients?

Should each client use a small sample of random nodes in the DC to connect to?

Or, should each client use all the nodes in the DC?

gak
  • 32,061
  • 28
  • 119
  • 154

3 Answers3

52

Answering my own question:

Seeds

From the FAQ:

Seeds are used during startup to discover the cluster.

Also from the DataStax documentation on "Gossip":

The seed node designation has no purpose other than bootstrapping the gossip process for new nodes joining the cluster. Seed nodes are not a single point of failure, nor do they have any other special purpose in cluster operations beyond the bootstrapping of nodes.

From these details it seems that a seed is nothing special to clients.

Clients

From the DataStax documentation on client requests:

All nodes in Cassandra are peers. A client read or write request can go to any node in the cluster. When a client connects to a node and issues a read or write request, that node serves as the coordinator for that particular client operation.

The job of the coordinator is to act as a proxy between the client application and the nodes (or replicas) that own the data being requested. The coordinator determines which nodes in the ring should get the request based on the cluster configured partitioner and replica placement strategy.

I gather that the pool of nodes that a client connects to can just be a handful of (random?) nodes in the DC to allow for potential failures.

Islam Hassan
  • 673
  • 1
  • 10
  • 21
gak
  • 32,061
  • 28
  • 119
  • 154
  • FYI, the FAQ link in the accepted answer is now superseded by http://cassandra.apache.org/doc/latest/faq/index.html#what-are-seeds. – swifthorseman Nov 28 '16 at 14:34
27

seed nodes serve two purposes.

  1. they act as a place for new nodes to announce themselves to a cluster. so, without at least one live seed node, no new nodes can join the cluster because they have no idea how to contact non-seed nodes to get the cluster status.
  2. seed nodes act as gossip hot spots. since nodes gossip more often with seeds than non-seeds, the seeds tend to have more current information, and therefore the whole cluster has more current information. this is the reason you should not make all nodes seeds. similarly, this is also why all nodes in a given data center should have the same list of seed nodes in their cassandra.yaml file. typically, 3 seed nodes per data center is ideal.

the cassandra client contact points simply provide the cluster topology to the client, after which the client may connect to any node in the cluster. as such, they are similar to seed nodes and it makes sense to use the same nodes for both seeds and client contacts. however, you can safely configure as many cassandra client contact points as you like. the only other consideration is that the first node a client contacts sets its data center affinity, so you may wish to order your contact points to prefer a given data center.

for more details about contact points see this question: Cassandra Java driver: how many contact points is reasonable?

Community
  • 1
  • 1
james turner
  • 2,773
  • 1
  • 21
  • 24
  • You wrote: "the seeds tend to have more current information, and therefore the whole cluster has more current information. this is the reason you should not make all nodes seeds.". It is not fully clear, why should one not make all nodes seed nodes then? Or should it be read like this: "nodes gossip more often with seeds than non-seeds... this is the reason you should not make all nodes seeds."? In that case, is the reason increased traffic between the nodes? – Richlv Nov 09 '16 at 20:45
  • 1
    here is an over-simplified example to make the math easy. say you have a cluster of 10 nodes, and each node syncs to 2 other nodes each minute. 1 sync is with a seed node and 1 with any node. now, imagine one of the non-seed nodes has an update to share with the cluster. if you have 1 seed node, then it will be updated this minute and everyone else will get updated the next minute. if you have 9 seed nodes, only two of them will get updated this minute, and only at most 8 will have the update the next minute. one node is guaranteed to not be updated. – james turner Nov 10 '16 at 15:09
  • Ah, that seems to go along with the link @the-paul shared in the other answer - https://wiki.apache.org/cassandra/ArchitectureGossip#Gossiper_implementation . Rephrasing a bit: "If the node gossiped to first was not seed, gossip to random seed". Thanks :) – Richlv Nov 10 '16 at 20:32
11

Your answer is right. The only thing I would add is that it's recommended to use the same seed list (i.e. in your cassandra.yaml) across the cluster, as a "best practices" sort of thing. Helps gossip traffic propagate in nice, regular rates, since seeds are treated (very minimally) differently by the gossip code (see https://cwiki.apache.org/confluence/display/CASSANDRA2/ArchitectureGossip).

Islam Hassan
  • 673
  • 1
  • 10
  • 21
the paul
  • 8,972
  • 1
  • 36
  • 53