Common operations and principles of MongoDB replica set

The following operations are mainly divided into two sections:

1. Modify Node State

Mainly include:

Demote the primary node to the secondary node
Freeze secondary nodes
Forcing secondary nodes into maintenance mode
2. Modify the configuration of the replica set

Adding nodes
Delete a node
To set the secondary node as a deferred backup node
To set the secondary node as a hidden node
Replace the current replica set member
Set the priority of a replica set node
Prevent secondary nodes from being promoted to primary nodes
How to set a secondary node without voting rights
Disable chainingallowed
To explicitly specify a replication source for a secondary node
Prevent secondary nodes from creating indexes

Start by looking at all the operations supported by the MongoDB replica set

Rs.help ()
Rs.status () {replsetgetstatus:1} checks Repl Set status
Rs.initiate () {replsetinitiate:null} initiates set with default settings
Rs.initiate (CFG) {replsetinitiate:cfg} initiates set with configuration cfg
Rs.conf () Get the current configuration object from Local.system.replset
Rs.reconfig (CFG) updates the configuration of a running replica set with CFG (disconnects)
Rs.add (HOSTPORTSTR) Add a new member to the set with default attributes (disconnects)
Rs.add (membercfgobj) Add a new member to the set with extra attributes (disconnects)
Rs.addarb (HOSTPORTSTR) Add a new member which is arbiteronly:true (disconnects)
Rs.stepdown ([Stepdownsecs, Catchupsecs]) step down as primary (disconnects)
Rs.syncfrom (HOSTPORTSTR) make a secondary sync from the given member
Rs.freeze (secs) make a node ineligible to become primary for the time specified
Rs.remove (HOSTPORTSTR) remove a host from the replica set (disconnects)
Rs.slaveok () Allow queries on secondary nodes

Rs.printreplicationinfo () Check oplog size and time range
Rs.printslavereplicationinfo () Check replica set members and replication lag
Db.ismaster () Check who is primary

Reconfiguration helpers disconnect from the database so the shell would display
An error, even if the command succeeds.
Modify Node State

Demote the primary node to the secondary node

Share:primary> Rs.stepdown ()
This command will downgrade primary to the secondary node and maintain 60s, which could require a re-election if no new primary are elected in the period.

You can also specify the time manually

Share:primary> Rs.stepdown (30)
After the command is executed, the original secondary node3:27017 is upgraded to primary.

Original primary node3:27018 reduced to secondary

Freeze secondary nodes

If you need to perform maintenance on primary, but do not want to elect other secondary nodes as primary nodes during the maintenance period, you can execute freeze commands on each secondary node, forcing them to always be in the secondary node state.

Share:secondary> Rs.freeze (100)
Note: Can only be performed on the secondary node

Share:primary> Rs.freeze (100)
{
"OK": 0,
"ErrMsg": "Cannot freeze node when primary or running for election. State:primary ",
"Code": 95,
"codename": "Notsecondary"
}

If you want to unfreeze the secondary node, simply perform

Share:secondary> Rs.freeze ()

Forcing secondary nodes into maintenance mode

When the secondary node enters maintenance mode, its state is converted to "RECOVERING", in which the client does not send a read request to it, and it cannot be used as a source of replication.

There are two triggering modes for entering maintenance mode:

1. Automatic triggering

For example, perform compression on secondary

2. Manual Trigger

Share:secondary> Db.admincommand ({"Replsetmaintenance": true})

Modifying the configuration of a replica set

Adding nodes

Share:primary> Rs.add ("node3:27017")
Share:primary> Rs.add ({_id:3, Host: "node3:27017", priority:0, hidden:true})
You can also configure the file by the way

cfg={
"_id": 3,
"Host": "node3:27017",
"Arbiteronly": false,
"Buildindexes": true,
"Hidden": true,
"Priority": 0,
"Tags": {

},
"Slavedelay": Numberlong (0),
"Votes": 1
}

Rs.add (CFG)

Delete a node

The first way

Share:primary> rs.remove ("node3:27017")
The second way

share:primary> cfg = rs.conf ()
Share:primary> Cfg.members.splice (2,1)
Share:primary> Rs.reconfig (CFG)
Note: Execution of rs.reconfig does not necessarily result in a re-election of the replica set, as is the case with the force parameter.

The Rs.reconfig () Shell method can trigger the current primary to step down in some situations.

Modifying the configuration of a node

To set the secondary node as a deferred backup node

CFG = rs.conf ()
cfg.members[1].priority = 0
Cfg.members[1].hidden = True
Cfg.members[1].slavedelay = 3600
Rs.reconfig (CFG)

To set the secondary node as a hidden node

CFG = rs.conf ()
cfg.members[0].priority = 0
Cfg.members[0].hidden = True
Rs.reconfig (CFG)

Replace the current replica set member

CFG = rs.conf ()
Cfg.members[0].host = "Mongo2.example.net"
Rs.reconfig (CFG)

Set the priority of a replica set node

CFG = rs.conf ()
cfg.members[0].priority = 0.5
Cfg.members[1].priority = 2
Cfg.members[2].priority = 2
Rs.reconfig (CFG)
The valid value of the priority is 0~1000, which can be a decimal, and the default is 1

Starting from MongoDB 3.2

Non-voting members must has priority of 0.
Members with the priority greater than 0 cannot has 0 votes.
Note: If the priority of the current secondary node is set greater than the priority of the primary node, it will cause the current primary node to abdicate.

Prevent secondary nodes from being promoted to primary nodes

Just set the priority to 0

FG = rs.conf ()
cfg.members[2].priority = 0
Rs.reconfig (CFG)

How to set a secondary node without voting rights

MongoDB restricts a replica set to a maximum of 50 member nodes, where up to 7 member nodes have voting rights.

This limitation is mainly due to the network traffic caused by the heartbeat request, after all, each member sends a heartbeat request to all other members, and the time spent on the election.

Starting with MongoDB 3.2, any node with priority greater than 0 cannot set votes to 0

Therefore, for secondary nodes that do not have voting rights, votes and priority must be set to 0 at the same time.

CFG = rs.conf ()
Cfg.members[3].votes = 0
cfg.members[3].priority = 0
Cfg.members[4].votes = 0
cfg.members[4].priority = 0
Rs.reconfig (CFG)

Disable chainingallowed

By default, cascading replication is allowed.

That is, if a new node is added to the backup set, the node is likely to replicate from one of the secondary nodes, rather than from the primary node.

MongoDB chooses the synchronization source according to the ping time, and one node sends a heartbeat request to another node to know the time spent on the heartbeat request. MongoDB maintains the average time spent on heartbeat requests between different nodes, selecting a synchronization source and choosing a node that is closer to you and more data than your own.

How do you tell which node the node is replicating from?

Share:primary> rs.status (). members[1].syncingto
node3:27018
Of course, there are obvious drawbacks to cascading replication: The longer the replication chain, the longer it takes to replicate the write operation to all the secondary nodes.

Can be disabled by the following way

Cfg=rs.conf ()
Cfg.settings.chainingallowed=false
Rs.reconfig (CFG)
When chainingallowed is set to false, all secondary nodes replicate data from the primary node.

To explicitly specify a replication source for a secondary node

Rs.syncfrom ("node3:27019")

Prevent secondary nodes from creating indexes

Sometimes, it is not necessary for the secondary node to have the same index as the primary node, for example, this node is only used to handle data backup or offline bulk tasks. At this point, you can prevent the secondary node from creating an index.

In MongoDB version 3.4, direct modification is not allowed and can only be explicitly specified when adding nodes

Share:primary> cfg=rs.conf ()
Share:primary> Cfg.members[2].buildindexes=false
False
Share:primary> Rs.reconfig (CFG)
{
"OK": 0,
"ErrMsg": "Priority must is 0 when Buildindexes=false",
"Code": 103,
"codename": "Newreplicasetconfigurationincompatible"
}
Share:primary> Cfg.members[2].buildindexes=false
False
Share:primary> cfg.members[2].priority=0
0
Share:primary> Rs.reconfig (CFG)
{
"OK": 0,
"ErrMsg": "New and old configurations differ in the setting of the Buildindexes field for member node3:27017; To make this C
hange, remove then re-add the member "," Code ": 103,
"codename": "Newreplicasetconfigurationincompatible"
}
Share:primary> rs.remove ("node3:27017")
{"OK": 1}
Share:primary> Rs.add ({_id:2, Host: "node3:27017", priority:0, Buildindexes:false})
{"OK": 1}

As you can see from the above test, if you want to set the node's buildindexes to False, you must set the priority to 0 at the same time.

Reference

1. The MongoDB authoritative guide

2. MongoDB Official documentation

3. Cloud computing Big Data MongoDB (https://www.yunchihair.com/?p=115)

Common operations and principles of MongoDB replica set