Re: Initialising / maintaining a list of nodes in the cluster
A cassandra cluster must always use the same rpc port default 9160 On Friday, September 6, 2013, Paul LeoNerd leon...@leonerd.org.uk wrote: 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? Thanks, -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Initialising / maintaining a list of nodes in the cluster
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? Thanks, -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
