MongoDB replica set node role introduction and election process analysis

MongoDB replica set node role introduction and election process analysis

A replica set ReplicaSet is generally composed of a group of mongod instances, which work together to provide highly available database access services.

Different Nodes in the replica set are MongoDB instances, but their roles are different. They are generally divided into three types: master node, replica node, and arbitration node.

Master node: Responsible for All Database write operations. By default, the master node is also responsible for All Database read operations;

Replica node: It is responsible for synchronizing the data operation logs of the master node to update the local database, so as to ensure the data consistency between the replica node and the data on the master node. In a sense, the replica node is a bit like a race, always catch up with data operations on the master node;

Arbitration node: it is not responsible for storing specific data. It only provides one vote for itself when the replica set performs master node election.

In addition to the above three role nodes, there are several other nodes, which are briefly described below:

Secondary-Only: As with the replica node, the data copy of the master node is saved, but it cannot become the Primary master node under any circumstances;

Hidden: This type of node is invisible to the client program and cannot become the Primary master node, but can participate in the voting;

Delayed: This type of node can be set manually to specify a time to delay data synchronization from the master node. The Delayed member is mainly used to recover old data from some misoperations, and certainly cannot become the master node and is a Hidden;

Generally, a minimal replica set consists of a master node, a replica node, and an arbitration node, most of them are composed of one master node and two replica nodes.

The structure of a minimal replica set is shown below:

In the replica set, the master node is responsible for processing all read and write operations from the client, and recording all database modification operations locally as log Oplog; the copy node actively and asynchronously operates logs from the master node at a certain frequency and acts on the database of the local node, thus ensuring data consistency between the copy node and the master node. Each node in the replica set performs a heartbeat request every two seconds to check the status of other nodes in the replica set.

Under normal circumstances, read/write operations are performed on the master node, and write operations cannot be controlled. They only work on the master node, but we can control the read Operations (read data from the replica node to achieve read/write splitting). At this time, we need to understand ReadPreference, below is a simple list of the modes available for us:

(1) primary: the default mode. All read operations are obtained from the master node;

(2) primaryPerferred: In most scenarios, read operations are performed directly from the master node. If the master node read operations are unavailable, they are read from the replica node;

(3) secondary: all read operations are read only from the copy node;

(4) secondaryPreferred: In most cases, read operations are performed from the replica node. If the replica node is unavailable, read from the primary node is considered;

(5) nearest: all read operations are performed on the node with the smallest network latency;

The above structure is a minimal replica set structure that can provide high-availability database access capabilities. But what happens to the entire replica set when the master node crashes or is temporarily unavailable?

(1) If the master node finds that it is unable to connect to most nodes in the replica set, in order to ensure data consistency, it will downgrade itself to a replica node to prevent operations from modifying the database;

(2) If the master node crashes and becomes unavailable, an election operation will be conducted in the replica Assembly to re-elect a master node;

The election process is as follows:

If the master node Primary is unavailable, the other two replica nodes will perform a heartbeat test with the other nodes every 2 seconds (normally, if you do not receive a response from the peer node within 10 s, the peer node is considered unavailable.) If you are eligible to become a replica node of the master node, an election proposal will be initiated to other nodes, I think I can become the master node. What do you think? ", Other nodes will determine the following conditions after receiving the proposed election:

(1) Is there any other node in the replica set already primary?

(2) Is your data updated compared to the data on the replica node that requests to become the master node?

(3) is the data of other nodes in the replica set updated compared with the data of the replica node that requests to become the master node?

If one of the above three conditions is met, the other party's proposal will be considered unfeasible. Therefore, a return packet will be returned and the request node will say, "I don't think you are a proper primary, stop the election! ", The request node immediately stops the election and keeps itself in the secondary role as long as it receives an inappropriate response from any other node. However, if none of the preceding conditions is met, then, the system will reply "I think you can accept _^" in the return package, and the request package will enter the second stage of the election. The request node will send a confirmation request packet to other nodes, which basically means "I have declared myself a primary. Is there any objection ?", If no other node has any objection during the confirmation process, the request node will upgrade itself to the primary node, and all nodes will not vote for other nodes within 30 seconds; if a node thinks that the request node is not suitable for primary, the request node will keep its node role as secondary after receiving the objection.

So far, we have briefly introduced the election process of each node role in the replica set and the primary node of the replica set. If you want to know more, you still need to see the detailed description on the Mongodb official website about the replica set, thank you.

Https://docs.mongodb.com/manual/core/replica-set-members/

For more MongoDB tutorials, see the following:

CentOS compilation and installation of php extensions for MongoDB and mongoDB

CentOS 6 install MongoDB and server configuration using yum

Install MongoDB2.4.3 in Ubuntu 13.04

MongoDB beginners must read (both concepts and practices)

MongoDB Installation Guide for Ubunu 14.04

MongoDB authoritative Guide (The Definitive Guide) in English [PDF]

Nagios monitoring MongoDB sharded cluster service practice

Build MongoDB Service Based on CentOS 6.5 Operating System

MongoDB details: click here
MongoDB: click here

This article permanently updates the link address: