Shulou(Shulou.com)06/01 Report--

The replication set of MongoDB can automatically tolerate the downtime of some nodes. When there is a problem with the replication set, it will trigger the election-related process and complete the automatic switching between master and slave nodes. Each replication set member runs the heartbeat thread of all nodes of the replication set in the background, triggering the state detection process in two cases:

The heartbeat detection results of replication set members change, such as a node is down or a new node is added; no status detection process is performed for more than 4 seconds. The state detection process roughly includes the following steps:

(1) check whether you are in the election process, and if so, withdraw from the process.

(2) maintain a standby list of primary nodes, in which all nodes may be elected as primary nodes, and each node will check whether its own and global conditions are met:

a. Whether you see Majority online in the replication set.

b. Its own priority is greater than 0.

c. Itself is not an arbiter.

d. Its own opTime cannot lag more than 10s behind the latest node.

e. The cluster programs stored by themselves are up-to-date according to information.

If all conditions are met, add yourself to the primary node standby list, otherwise, remove yourself from the list.

Check the following conditions, if all are met, degrade the master node to the slave node (if the master node to be degraded is itself, call the demotion method directly, if not for yourself, call the replSetStepDown command to demote the replication set master node to slave node: a. The primary node exists in the cluster. b. There is a node higher than the priority of the current primary node in the standby list of primary nodes. c. The node with the highest priority in the standby list of primary nodes has an opTime less than 10s behind the latest opTime of all other nodes. d. Check whether it is the master, and if it is the master, and the Majority of the replication set cannot be seen by itself, downgrade itself to slave. e. If you do not see a primary node in the cluster, check if you are in the "standby list of primary nodes". If not, print the log and exit the process. f. If you start to judge whether you can send a notification of electing your own primary node to the replication set in the "standby list of primary nodes", the judgment process includes: 1 > whether you can see the Majority online in the replication set. 2 > whether you are in the standby list of the primary node.

If the conditions are met, set the "oneself is already in the election process" identification bit to true, and enter the "elect itself master node" method.

Method verifies that it meets the following conditions:

a. This thread got the thread lock.

b. This node is not configured with the slaveDelay option or the configured slaveDelay is 0.

c. This node is not configured as arbiter.

If it is met, the environment detection will be called. If the following conditions are triggered, the "vote me Master" poll will not be sent:

1 > the current time is less than the end freeze time of steppedDown (set time for the execution of steppedDown + freeze time, internal call is 60s).

2 > your own opTime is not up to date on all nodes.

3 > if the opTime of a node is newer than it is, exit this process directly.

If the other newest nodes are at most as new as they are, each such node is randomly sleep for a period of time, and then continue to judge.

a. Within 5 minutes of self-launch and not all nodes in the replication set are online.

b. If there are no other questions, try to get the number of votes when you vote. in the process, you will judge whether you have voted within 30 seconds, and if so, directly withdraw from the whole process.

After all these complex tests, we can finally send a vote to "elect me as the master node" to the replica set.

After sending, it will receive votes from all nodes. If the number of votes is less than or equal to half, it will not become the master node. If it is more than half, set itself as the master node.

After voting closes, set the "oneself is already in the election process" flag bit to false.

It can be seen that some of the above judgment logic is repeated judgment, but it does not affect the final result, and may have something to do with the complexity of the judgment logic. Before each decision, it is necessary to verify whether all the conditions are met to prevent the conditions from being missed.

When a node in the replication set receives the "vote me Master" vote message sent by another node, the following judgment will be made:

a. If the configuration version of the replication set stored by yourself is too low, do not vote.

b. If the replication set configuration version stored by the requesting node is too low, vote against it.

c. If you are in a replica set that does not have a node to initiate a vote, vote against it.

d. There is a master node in the replication set and vote against it.

If there are nodes whose priority is higher than the request, they will vote against it.

If all the conditions are passed, get your own number of votes (you will also judge whether you have participated in the vote within 30 seconds, and if so, no longer vote), and cast the number of votes.

It is important to say that an objection reduces the final number of votes by 10000, that is, in the vast majority of cases, as long as a node objects, the requesting node cannot become the primary node.

The election process is very complicated and can be summarized into two points in practical use:

In general, it takes about 5 seconds to choose the main person.

If the newly elected master node dies immediately, it will take at least 30 seconds to re-elect the master.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.