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

This article will explain in detail how the MongoDB copy collection operation and maintenance strategy is, and the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

P1 rolling maintenance / upgrade

The maintenance / upgrade of the MongoDB replica set is usually performed in a scrolling manner, performing maintenance on the secondary node in turn, and finally the primary node maintenance.

Stop the MongoDB service on the secondary node, perform the operation and maintenance operation to start the MongoDB service on the server and wait for the node's MongoDB to be synchronized to the latest Oplog (catch-up) repeat the above operation on other secondary nodes in the replica set

Suppose a replica set contains mon01 (primary node) and mon02 (secondary) mon03 (secondary). Rolling operation and maintenance usually requires:

Perform maintenance on the secondary node mon03 and mon02 successively to downgrade the primary node mon01 (stepDown) and wait for the election of a new primary node. For example, mon02 performs maintenance on the previous primary node mon01.

If the primary server terminates unexpectedly / most secondary nodes feel that they have lost contact with the primary node, the secondary node will require an election 10 seconds after losing the heartbeat.

P2 Fast Election Primary Node downgraded, trigger Quick Election

StepDown the primary node can speed up the failover process. It is recommended to use the stepDown command to force the election to be triggered, rather than shutDownServer the primary database (it takes time for the secondary node to identify that the primary node is missing)

Reduce electionTimeoutMillis threshold

The default threshold for the secondary node to determine that the primary node is missing is 10s. During rolling maintenance, we can artificially shorten this threshold and speed up the election. But after the operation and maintenance, please restore this default setting.

Rs.isMaster () me

/ / mon02:27000

/ / rs0:PRIMARY >

/ / on the new primary

Var conf = rs.conf ()

Conf.settings.electionTimeoutMillis=10000

/ *

Rs.reconfig (conf)

{

"ok": 1

OperationTime: Timestamp (1529034252, 1)

"$clusterTime": {

ClusterTime: Timestamp (1529034252, 1)

"signature": {

"hash": BinData (0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA=")

"keyId": NumberLong (0)

}

}

}

, /

"

A threshold of 10s is appropriate, and we need to ensure that the cluster can ignore and tolerate network jitter or network latency and reduce unnecessary reselection.

P3 preferred new master node

In general, the primary node is selected based on the following factors

Low replication lag and low network latency

If you want to designate a secondary node mon02 as the next primary node, run rs.freeze (60) on other secondary nodes to freeze their eligibility to become the primary node; when you stepDown the primary node mon01, the secondary node mon02 is the only primary node that can be selected, which will speed up the election.

Or

You can make a replica set member a master node by giving it a higher member [n] .priority value than other members.

Cfg = rs.conf ()

Cfg.members [0] .priority = 0.5

Cfg.members [1] .priority = 0.5

Cfg.members [2] .priority = 1

Referenced operation and maintenance commands:

Rs.conf () returns the document containing the current replica set configuration rs.sttaus () returns the replica set status received from a member's perspective rs.stepDown (stepDownSecs, secondaryCatchUpPeriodSecs) indicates that the primary node is degraded into a secondary node, after which the qualified secondary node will initiate an election; in addition, it is not immediately degraded, waiting for a specified time to ensure that a node is up-to-date with the primary node. Rs.freeze (seconds) freezes the qualification of a node to become a master node within a certain period of time rs.reconfig (configuration, force) reconfigures the existing replica set to overwrite the existing replica set configuration (need to be connected to the master node for execution). This is the end of the MongoDB replica set operation and maintenance policy. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.