A brief analysis of the role introduction and election process of MongoDB's replica set node

A replica set replicaset typically consists of a set of Mongod instances, which coordinate and work together to provide a highly available database access service to the outside.

Although the different nodes in the replica set are Mongod instances, there are different roles, generally divided into three kinds: master node, replica node, and arbiter node.

Master node: Responsible for all the database write operations, by default, the master node is also responsible for processing all database read operations;

Replica node: The data operation Log that is responsible for synchronizing the master node updates the local database to ensure the consistency of the data on the replica node and the data on the master node; The replica node is a bit like a race in a sense, always chasing the data operations of the master node;

Quorum node: It is not responsible for saving specific data, only providing one vote for the replica set when the master node is elected.

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

Secondary-only: The copy of the master node is saved as the replica node, but it cannot be the primary master node under any circumstances;

Hidden: This type of node is not visible to the client program, also cannot become the primary master node, but can participate in voting;

Delayed: This type of node can be artificially set, can specify a time to delay the synchronization of data from the primary node, Delayed members are mainly used to recover old data from some misoperation, and must not become the primary node and is hidden;

In general, a minimized replica set consists of one master node, one replica node, and one quorum node, but in practice, most of them are made up of one master node and two replica nodes.

A structure diagram of a minimized replica set is as follows:

In, the primary node in the replica set is responsible for handling all read and write operations from the client and logging all the operations that modify the database locally on a log oplog, and the replica nodes are actively and asynchronously from the primary node to the database on their own natively, at a certain frequency. This ensures data consistency between the replica node and the master node. A heartbeat request is made every 2 seconds between each node in the replica set to see the status of the other nodes in the replica set.

Under normal circumstances, read and write operations on the master node, write operations we are unable to control, only on the primary node, but for the read operation we can really control (read data from the replica node, so as to achieve read and write separation), this time we need to understand readpreference, Below is a simple list of what patterns are available for us to choose from:

(1) Primary: By default, all read operations are obtained from the master node;

(2) Primaryperferred: read from the primary node directly in most scenarios and read from the replica node if the primary node read operation is not available;

(3) Secondary: All read operations are read only from the replica node;

(4) Secondarypreferred: In most scenarios, read operations are read from the replica node, if the replica node is not available, then consider reading from the primary node;

(5) Nearest: All read operations are read from nodes with the least network latency;

The above structure is a minimal replica set structure that can provide high availability of database access externally, but what happens to the entire replica assembly when the primary node crashes or is temporarily unavailable?

(1) If the master node finds itself and most of the nodes in the replica set cannot connect, it will downgrade itself to a replica node to ensure data consistency, thereby preventing the operation from modifying the database;

(2) If the primary node crashes and is unavailable, an election operation will be conducted within the replica assembly to re-elect a master node;

The process for elections is as follows:

, the primary node primary hypothesis is not available, then the other two replica nodes in the discovery and the primary node is unable to heartbeat (normally, each node every 2 seconds with the other nodes a heartbeat test, if not received within 10s of the other node's reply, the other node is considered not available), A replica node that qualifies as the master node will initiate an election proposal to the other nodes, basically meaning "I think I can be the master node, don't you think?" , and the other nodes will judge the following conditions upon receipt of the election proposal:

(1) Are there other nodes in the replica set that are already primary?

(2) is your data updated than the data on the replica node that is requested to be the primary node?

(3) is the data of the other nodes in the replica set more than the data updates of the replica nodes that are requested to be the primary node?

If one of the above three conditions is satisfied, then the other's proposal is considered not to be possible, so return a return packet to the request node and say "I think you are primary inappropriate, stop the election!", the request node will stop the election as soon as any other node returns. And keep yourself in the secondary role, but if none of the above three conditions are met, you will return to the package and say "I think you can ^_^", then the request package will enter the second phase of the election. " The request node sends a confirmation request packet to the other node, basically meaning "I declare myself to be a primary, is anyone against it?" "If the other nodes in this confirmation process are not objected to, then the request node will upgrade itself to the primary node, all nodes in 30 seconds no longer the other election voting decision, if there is a node at this time that the request node is not suitable to do primary, Then the request node will keep its node role secondary after receiving an objection reply.

At this point, we simply say that the copy set of the various node roles and replica set the main node of the election process, if you want to know more, or need to see the MongoDB official website about the copy set of the detailed description, thank you.

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

A brief analysis of the role introduction and election process of MongoDB's replica set node