Database Reference
In-Depth Information
Ring membership
We have been talking about the ring membership of DynamoDB since the start. There
might be a number of reasons to add or remove nodes from a DynamoDB cluster, such as
storage outage, power /network disk failure, and so on. Some node failures might be tem-
porary and need not require load balancing, as it can be time consuming and unnecessary.
This is because after some time the node would be back. Similarly, someone can accident-
ally trigger a new node that might be taken off in minutes. So, it would be time consuming
to do load balancing for all such accidental and temporary membership changes.
Keeping this in mind, DynamoDB relies on the administrator to initiate a membership
change request and inform any one member in the DynamoDB cluster. The administrator is
provided with a command line and browser tool to perform node addition or deletion. The
node to whom the administrator initiates the membership change request writes the changes
to other member nodes. A history is maintained to keep track of all membership change re-
quests. DynamoDB uses a gossip-based protocol to propagate the changes made to its
membership. Gossip protocol is a computer-to-computer communication style, where one
computer initiates a communication with some computers, and then these computers for-
ward the message to other computers, and so on. You can read more about gossip protocol
For the new node joining the cluster, it has to first choose the range of tokens on the hash
ring. It also needs to have virtual nodes placed at various logical points on the hash ring.
Once the node joins the ring, it has to take information from all the other nodes and the
range of tokens/keys they handle, and vice versa. Each node needs to be aware of the token
ranges handled by its peers in order to forward the requests to appropriate nodes.
The following diagram pictorially represents how membership changes are propagated to
all nodes in a DynamoDB cluster:
