MongoDB Data Synchronization

MongoDB replica set (V3.0) synchronizes member status information through heartbeat information. Each node periodically sends heartbeat information, such as the replica set status information shown in the rs.status() method, to other members in the replica set.

The node initiating the heartbeat request is called the source, and the member receiving the heartbeat request is the target. A heartbeat request is divided into three phases.

The source sends a heartbeat request to the target.

The target handles the heartbeat request and sends a response to the source.

The source receives a heartbeat response and updates the status of the target node.

Let us examine the main state synchronization logic in these three phases.

In the default configuration, nodes of a replica set send a heartbeat request to the other members once every two seconds, namely the replSetHeartbeat command request. The content of the heartbeat request is similar to the one shown below (obtained through mongosniff packet capturing). It mainly contains the replSetName, the address of the heartbeat sending node, and the replica set version.

When a member in the replica set receives a heartbeat request, it begins processing the request and returns the processing result to the requesting node.

If the node is not of the replica set mode, or the replica set name does not match, an error response will be returned. If the replica set version configured (the content of rs.conf()) for the source node is lower than that of the target node, the target node adds its own configuration to the heartbeat response message, and adds its own oplog and other status information to the heartbeat response message. If the target node is uninitialized, it immediately sends the heartbeat request to the source node to update its replica set configuration.

Phase 3 is the most important part of processing. After receiving the heartbeat response, the source node will update the status of the peer node according to the response message and determine whether a re-election is required based on the final status.

MongoDB synchronizes information between nodes through heartbeats and triggers the election to achieve final consistency in the replica set.

However, there is no theoretical basis for the correctness of the process. In MongoDB 3.2, a new version of the replica set communication protocol is used and election is conducted through raft, which can further shorten the time for fault discovery and instance restoration.