Gossip Protocol

Gossip In Cassandra


Each Node initiates a gossip round every second , it can pick 1-3 nodes to gossip


Node do not track which nodes they gossip with prior. 


It efficiently and reliably spreads the node metadata through the cluster. 



Example


Endpoint State: 

   IP Address: 192.168.1.10 

   Status: UP 

   Load 5 GB

  Heartbeat State: 

  Generation=5.     (Timestamp of when node is bootstrapped)   

  Version= 22 (increment version for every gossip)

  Application Status:

Status = NORMAL

      DC= west

  RACK= rack1

   




Comments

Post a Comment

Popular posts from this blog

Peer to Peer Architecture

   Peer to Peer Architecture in Apache Cassandra   In Cassandra’s peer-to-peer architecture, every node in the cluster is equal, meaning there is no single master node that controls other nodes. Instead, all nodes work together to handle read and write requests, replication, and data distribution. This allows Cassandra to achieve high availability and fault tolerance. Here’s how this architecture works: Key Features of the Peer-to-Peer Architecture: 1.  Decentralized Design (No Master Node): There is no master or primary node in Cassandra. All nodes in the cluster are peers, which means that they can perform the same tasks (like handling read/write requests, holding replicas, and distributing data). This eliminates the risk of a single point of failure and makes the system more fault-tolerant. 2.  Data Distribution: Data is distributed across nodes in the cluster based on a hashing function. Each node is responsible for a specific range of data, known as its tok...
Read more

Read Repair Chance

Image
Read Repair Chance When a read request is made with consistency as ALL   Coordinator Node send the data request to nearest node   Coordinator Node send the checksum request from replica node Once it receives the responses it checks all the checksum values. If they are all same as below value 23 If. Values are different as below from replica nodes Coordinator nodes checks the checksum which has the latest timestamp , it discards the data from replica node which has stale data. Coordinator node sends the correct data on the replica node on which data is deleted  
Read more

Node

Image
  Apache Cassandra Node But as the load on single node increases node gets to crack We just add more nodes to the ring   Data is distributed evenly across the ring nodes Each node is assigned a token range   How does cassandra retrieve the data from the correct node ? Query using partition key only:   When we query data using partition key   eg: select * from users where user_id=1234;   Cassandra takes the partition key and calculates the hash value using default Murmur3 algorithms   Calculated hash value of the partition key is the Token. Cassandra takes the token and identifies which node can handle this token range. Once cassandra identifies the node it sends the query , if we have replication factor then it sends to multiple nodes depends on the replication factor and consistency level.   Once data is retrieved from the multiple nodes then it checks which replica node has the latest timestamp   Cassandra then sends the data to the client....
Read more