Configuring gossip settings

Using the cassandra.yaml file to configure gossip.

When a node first starts up, it looks at its cassandra.yaml configuration file to determine the name of the Cassandra cluster it belongs to; which nodes (called seeds) to contact to obtain information about the other nodes in the cluster; and other parameters for determining port and range information.

The location of the cassandra.yaml file depends on the type of installation:
Package installations /etc/cassandra/cassandra.yaml
Tarball installations install_location/resources/cassandra/conf/cassandra.yaml


In the cassandra.yaml file, set the following parameters:
cluster_name Name of the cluster that this node is joining. Must be the same for every node in the cluster.
listen_address The IP address or hostname that Cassandra binds to for connecting to other Cassandra nodes.
(Optional) broadcast_address The IP address a node tells other nodes in the cluster to contact it by. It allows public and private address to be different. For example, use the broadcast_address parameter in topologies where not all nodes have access to other nodes by their private IP addresses. The default is the listen_address.
seed_provider A -seeds list is comma-delimited list of hosts (IP addresses) that gossip uses to learn the topology of the ring. Every node should have the same list of seeds. In multiple datacenter clusters, the seed list should include at least one node from each datacenter (replication group). More than a single seed node per datacenter is recommended for fault tolerance. Otherwise, gossip has to communicate with another datacenter when bootstrapping a node. Making every node a seed node is not recommended because of increased maintenance and reduced gossip performance. Gossip optimization is not critical, but it is recommended to use a small seed list (approximately three nodes per datacenter).
storage_port The inter-node communication port (default is 7000). Must be the same for every node in the cluster.
initial_token For legacy clusters. Used in the single-node-per-token architecture, where a node owns exactly one contiguous range in the ring space.
num_tokens For new clusters. Defines the number of tokens randomly assigned to this node on the ring when using virtual nodes (vnodes).