Gossip in Cassandra

Dear Readers,

In this article we will see Gossip in Cassandra.

Gossip

Gossip is a peer-to-peer communication protocol to discover and share the location and state information about the other nodes in a Cassandra cluster. Gossip information is also persisted locally by each node to use immediately when a node restarts.

During a gossip nodes exchange following information.

Ø  status	Ø  health
Ø  tokens	Ø  schema version
Ø  addresses	Ø  data size    etc…

 

A gossip message has a version associated with it. during a gossip nodes exchange information along with version so the older information is overwritten with the most current state for a particular node.

 

Cassandra Gossip Terminology.

Seed node.

In Cassandra which node is starting the gossip and exchange the new version of information with other node’s is called the seed node.

In multiple data-center clusters the seed list should include at least one node from each datacenter. More than a single seed node per datacenter is recommended for fault tolerance.

 

 

Listener address and storage port.

Cassandra uses the listener_address and storage port for the inter-node communication. 7000 is the default port id for Cassandra. the port id Must be the same for every node in the cluster.

listener_address= ip address of node

storage_port = 7000

 

 

The gossip process tracks state from other nodes both directly and indirectly. which reduce the network latency.

 

Gossiper is responsible for making sure every node in the cluster eventually knows important information about every other node’s state.

 

 

Failure detection and recovery      

The gossip process tracks the state of nodes both directly and indirectly. in this process Cassandra checks the health of each and every node in the cluster. it helps Cassandra to detect the failure of any node in the cluster easily.

The Failure detection is a method for locally determining from gossip state and history if another node in the system is down or has come back up.

Node failures can result from various causes such as hardware failures and network outages. Cassandra uses this information to avoid routing client requests to unreachable nodes whenever possible.

Cassandra manages failure detector sensitivity using phi_convict_threshold value  in cassandra.yaml file.

 

Thank you for giving your valuable time to read the above information. Please click here to subscribe for further updates

KTEXPERTS is always active on below social media platforms.

Facebook : https://www.facebook.com/ktexperts/
LinkedIn : https://www.linkedin.com/company/ktexperts/
Twitter : https://twitter.com/ktexpertsadmin
YouTube : https://www.youtube.com/c/ktexperts