cassandra-client-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul "LeoNerd" Evans <>
Subject Initialising / maintaining a list of nodes in the cluster
Date Fri, 06 Sep 2013 22:29:51 GMT
I'm trying to work out how a client is best to maintain a list of what
nodes are available in the cluster, for maintaining connections to.

I understand the general idea is to query the "system.peers" table, and
REGISTER an interest in TOPOLOGY_CHANGE and STATUS_CHANGE messages to
watch for nodes being added/removed or becoming unavailable/available.
So far so good.

A few details of this seem a bit awkward though:

 * The "system.peers" table identifies peers only by their IP address,
   not including the port number, whereas TOPOLOGY and STATUS_CHANGE
   messages include a port.

   What happens if there is more than one copy of a node using the same
   IP address? How do I know which TCP port I can use to communicate
   CQL with a given peer?

 * The "system.peers" table doesn't contain any information giving the
   current availability status of the nodes, so I don't know if they
   are initially up or down.

   I can just presume all the known nodes are up until I try connecting
   to them - in any case, it could be that Cassandra knows of the
   existence of nodes that for some reason my client can't connect to,
   so I'd have to handle this case anyway. But it feels like that hint
   should be there somewhere.

 * The "system.peers" table doesn't include the actual node I am
   querying it on.

   Most of the missing information does appear in the "system.local"
   table, but not the address. The client does know /an/ address it has
   connected to that node using, but how can I be sure that this
   address is the one that will appear in the "peers" list on other
   nodes? It's quite common for a server to have multiple addresses, so
   it may be that I've connected to some address different to that
   which the other nodes know it by.

I'm quite new to Cassandra, so there stands a chance I've overlooked
something somewhere. Can anyone offer any comment or advice on these
issues, or perhaps point me in the direction of some client code that
manages to overcome them?


Paul "LeoNerd" Evans
ICQ# 4135350       |  Registered Linux# 179460

View raw message