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

The following actions are mainly divided into two parts:

Modify node statu

It mainly includes:

Downgrade Primary node to Secondary node

Freeze Secondary nod

Force the Secondary node to enter maintenance mode

two。 Modify the configuration of the replica set

Add nod

Delete nod

Set the Secondary node as a deferred backup node

Set the Secondary node as a hidden node

Replace the current replica set member

Set the priority of the replica set node

Prevent Secondary nodes from upgrading to Primary nodes

How to set up Secondary nodes without voting rights

Disable chainingAllowed

Explicitly specify the replication source for the Secondary node

Prohibit Secondary nodes from creating indexes

First look 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]) stepdown 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 will display

An error, even if the command succeeds.

Modify node statu

Downgrade Primary node to Secondary node

Share:PRIMARY > rs.stepDown ()

This command degrades the primary to a Secondary node for 60 seconds, and if no new primary is elected during that time, the node can ask for re-election.

You can also specify the time manually

Share:PRIMARY > rs.stepDown (30)

After executing the command, the original Secondary node3:27017 was upgraded to Primary.

The original Primary node3:27018 was reduced to Secondary

Freeze Secondary nod

If you need to maintain the Primary, but do not want to elect other Secondary nodes as Primary nodes during the maintenance period, you can execute the freeze command on each Secondary node to force them to always be in the Secondary node state.

Share:SECONDARY > rs.freeze

Note: can only be executed on Secondary nodes

Share:PRIMARY > rs.freeze

{

"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 execute

Share:SECONDARY > rs.freeze ()

Force the Secondary node to enter maintenance mode

When a Secondary node enters maintenance mode, its state changes to "RECOVERING". In this state, the client does not send a read request to it, and it cannot be used as a replication source.

There are two triggers for entering maintenance mode:

Automatic trigger

For example, perform compression on Secondary

Manual trigger

Share:SECONDARY > db.adminCommand ({"replSetMaintenance": true})

Modify the configuration of the replica set

Add nod

Share:PRIMARY > rs.add ("node3:27017")

Share:PRIMARY > rs.add ({_ id: 3, host: "node3:27017", priority: 0, hidden: true})

It can also be done through configuration files.

Cfg= {

"_ id": 3

"host": "node3:27017"

"arbiterOnly": false

"buildIndexes": true

"hidden": true

"priority": 0

"tags": {

}

"slaveDelay": NumberLong (0)

"votes": 1

}

Rs.add (cfg)

Delete nod

The first way

Share:PRIMARY > rs.remove ("node3:27017")

The second way

Share:PRIMARY > cfg = rs.conf ()

Share:PRIMARY > cfg.members.splice (2jue 1)

Share:PRIMARY > rs.reconfig (cfg)

Note: performing a rs.reconfig does not necessarily result in a re-election of the replica set, as does the addition of the force parameter.

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

Modify the configuration of the node

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)

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 the 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 priority is 0,1000, which can be a decimal, and the default is 1.

Since MongoDB 3.2,

Non-voting members must have priority of 0.

Members with priority greater than 0 cannot have 0 votes.

Note: if the priority of the current Secondary node is greater than that of the Primary node, it will cause the abdication of the current Primary node.

Prevent Secondary nodes from upgrading to Primary nodes

Just set priority to 0

Fg = rs.conf ()

Cfg.members [2] .priority = 0

Rs.reconfig (cfg)

How to set up Secondary nodes without voting rights

MongoDB limits a replica set to a maximum of 50 member nodes, of which up to 7 member nodes have the right to vote.

The main reason for this restriction is to take into account the network traffic caused by heartbeat requests. after all, each member has to send heartbeat requests to all other members, and the time it takes to elect.

Starting with MongoDB 3.2, no node with a priority greater than 0 can set votes to 0

Therefore, for Secondary nodes that do not have voting rights, both votes and priority must be set to 0

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

Cascading replication is allowed by default.

That is, if a new node is added to the backup set, it is likely to be replicated from one of the Secondary nodes rather than from the Primary node.

MongoDB selects the synchronization source according to the ping time, and one node sends a heartbeat request to another node to know how long the heartbeat request takes. MongoDB maintains the average time spent on heartbeat requests between different nodes. When selecting a synchronization source, it selects a node that is closer to it and whose data is newer than its own.

How can you tell from which node the node is replicated?

Share:PRIMARY > rs.status (). Members [1] .syncingTo

Node3:27018

Of course, cascading replication has an obvious drawback: the longer the replication chain, the longer it takes to replicate writes to all Secondary nodes.

You can disable it by

Cfg=rs.conf ()

Cfg.settings.chainingAllowed=false

Rs.reconfig (cfg)

When chainingAllowed is set to false, all Secondary nodes copy data from the Primary node.

Explicitly specify the replication source for the Secondary node

Rs.syncFrom ("node3:27019")

Prohibit 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 backups or offline batch tasks. At this point, you can prevent the Secondary node from creating the index.

In MongoDB 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 be 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 tests, if you want to set the node's buildIndexes to false, you must also set priority to 0.

Referenc

1. MongoDB authoritative Guide

MongoDB official documentation

Cloud computing big data mongodb (https://www.yunchihair.com/?p=115)

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.