Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to maintain the mongodb replication set. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

I. add members of the replica set

1. Log in to primary

2. Use admin > rs.add ("new_node:port") or rs.add ({"_ id": 4, "host": "new_node:port", "priority": 1, "hidden": false})

3. Use admin > rs.addArb ("new_node;port") or rs.addArb ({"_ id": 5, "host": "new_node:port"}) or rs.add ({'_ id':5, "host": "new_node:port", "arbiterOnly": true})

The only role of the arbitrator is to participate in the election. The arbitrator does not keep the data or provide services to the client. Once a member joins the copy set as an arbitrator, it can always be an arbitrator and cannot be an arbitrator.

Reconfigure as a non-arbitrator and vice versa. There can be at most one arbitrator in each copy set.

Note: if priority=1 in the replication set (default), calling rs.add ("new_node:port") this command will result in a master-slave switch, that is, an election operation

If priority=1 in the replication set (default), calling rs.remove ("new_node:port") directly will also result in a master-slave switch

Delete replica set members

1. Log in to the target mongodb instance to be removed

2. Use the shutdownServer () command to close the instance; that is, db.shutdownServer ()

3. Log in to the primary of the replication set

4. Primary > use admin

Primary > rs.remove ("del_node:port")

Third, modify the priority and concealment of members

1. Log in to primary

2. Use admin > conf=rs.conf ()

Mongo > conf.members [1] .priority = [0-1000]

Mongo > conf.members [1] .hidden = true # priority must be 0

Mongo > conf.members [9] .tags = {"dc": "tags_name1"}

Mongo > rs.reconfig (conf); # Force reconfiguration of rs.reconfig (conf, {"force": true})

The properties of members have the following options

[, arbiterOnly: true]

[, buildIndexes:]

[, hidden: true]

[, priority:]

[, tags: {loc1: desc1, loc2: desc2,..., locN: descN}]

[, slaveDelay:] # seconds.

[, votes:]

If the member is to be set to hidden:true or slaveDelay:30, its priority priority must be set to 0

In other words, the priority of hidden members and deferred members and members of buildIndexs:false must be 0, that is, priority=0.

A member with priority 0 cannot initiate an election operation.

As long as the priority is > 0, the member can become the primary node even if the member is not eligible to vote.

If the index structure of a node is inconsistent with the index structure on other nodes, the node will never become the primary node.

Priority is used to indicate the extent to which a member aspires to be a master node. The value range of priority is [0-100], and the default is 1. A member with a priority of 0 can never become a primary node.

Using rs.status () and rs.config (), you can see hidden members, which are only invisible to rs.isMaster (). When the client connects to the replica set, rs.isMaster () is called.

To view the available members. To set a hidden member as a non-hidden member, simply set the hidden in the configuration to false, or remove the hidden option.

Each member can have multiple tags tags {"dc": "tags_name2", qty: "tag_name3"}

Votes:0 representatives prevent these members from voting actively in the election, but they can still vote no.

Restrictions when modifying the configuration of replica set members:

1. Cannot modify _ id

2. The priority of the member receiving the rs.reconfig command cannot be set to 0.

3. An arbitrator member cannot be turned into a non-arbitrator member, anyway.

4. You can't change buildIndexes:false to true

4. Check the data synchronization (delay) of the members of the replica set

Mongo > db.printReplicationInfo ()

Mongo > db.printSlaveReplicationInfo (); # it's best to execute on secondary

Mongo > rs.printReplicationInfo ()

Mongo > rs.printSlaveReplicationInfo ()

Mongo > use local > db.slaves.find ()

Track delays on the primary node:

Local.slaves this collection holds all members that are synchronizing data from the current member, as well as the old and new data of each member.

Log in to the primary node

> use local

> db.slaves.find (),

Look at the corresponding "syncedTo": {"t": 9999999, "I": 32} sections of each of these members to know the degree of data synchronization.

The value of the "_ id" field is the server identifier for each current member. You can view this server identifier in each member's local.me.find ().

1 、

If multiple servers have the same _ id identifier, log in to each server member in turn, delete the local.me collection (local.me.dorp ()), and then restart mongodb

When mongod is restarted, mongod regenerates the local.me collection with the new "_ id".

2. If the address of the server changes but _ id does not change, and the host name changes, you will see a duplicate key exception (duplicate key exception) in the log of the local database.

The solution is to delete the local.slaves collection without restarting mongod.

Because mongod does not clean up the local.slaves collection, the data in it may be inaccurate or too old, and the entire collection can be deleted. When a new server uses the current member as

When you copy a source, the collection is regenerated. If you see that a particular server has multiple documents in the collection in the primary node, it means that a replication chain has occurred between the backup nodes

This situation does not affect data synchronization, but simply tells the primary node the synchronization source of each backup node.

Delete the local.me collection, need to restart the mongod,mongod startup will use the new _ id to regenerate the local.me collection.

Delete the local.slaves collection without restarting mongod. The data in this collection is the data of the server that records the member as the synchronization source. This collection is used to report the status of the copy set.

Shortly after deletion, if a new node member uses the server node as the replication source, the collection is regenerated.

Fifth, the primary node is reduced to secondary

Mongo > use admin

Mongo > rs.stepDown (60) # in seconds

Lock the specified node cannot become the primary node within a specified period of time (prevent elections)

Mongo > rs.freeze (120) # in seconds

Release blocking

Mongo > rs.freeze (0)

Force the node to enter maintenance mode (recovering)

You can force a member into maintenance mode by executing the replSetMaintenanceMode command.

For example, if a member is automatically detected to be behind the master node for a specified time, it will be transferred to maintenance mode:

Function maybeMaintenanceMode () {

Var local=db.getSisterDB ("local")

If (! local.isMaster (). Secondary)

{return

)

Var last=local.oplog.rs.find () .sort ({"$natural":-1}) .next ()

Var lasttime=last ['ts'] [' t']

If (lasttimedb.adminCommand ({shutdownServer:1}))

2. Restart the mongod as a stand-alone machine (comment out the replSet shardsvr in the configuration file and modify the port number)

3. Save the last insert operation record in local.oplog.rs to a temporary collection

Mongo > use local

Mongo > var cursor=db.oplog.rs.find ({"op": "I"})

Mongo > var lastinsert=cursor.sort ({$natural:-1}) .limit (1) .next ()

Mongo > db.templastop.save (lastinsert)

Mongo > db.templastop.findOne () # make sure to write

4. Delete oplog.rs: db.oplog.rs.drop ()

5. Create a new oplog.rs collection: db.createCollection ("oplog.rs": {"capped": true, "size": 10240})

6. Write the last insert operation record in the temporary collection back to the newly created oplog.rs:

Var temp=db.templastop.findOne ()

Db.oplog.rs.insert (temp)

Db.oplog.rs.findOne () # make sure you write it back, otherwise the node rejoining the replica set will delete all data on that node and then resynchronize all data.

Finally, restart the node as a member of the replica set.

12. Set options for replica set members

That is, when you run the rs.initiate (replSetcfg) or rs.add (membercfg) options, you need to provide a specific configuration structure that describes the members of the replication set:

{

_ id:replSetName

Members:

[

{_ id:,host:

The default value of [priority:,] # is 1.0. That is, the value of the option is floating point.

[hidden:true,] # this element hides the node from the output of db.isMaster ().

[arbiterOnly:true,] # default is false

[votes:,] # the default value is 1. Change the value of the option to shaping

[tags: {documents},]

[slaveDelay:,]

[buildIndexes:true,] # the default value is false. This option is used to disable the creation of indexes.

}]

Settings: {

[chainingAllowed:,] # specifies whether the member is allowed to replicate data from other secondary servers. The default value is true

[getLastErrorModes:,] # mode: used to customize write concerns settings

[getLastErrorDefaults:,] # default value: used to customize write concerns settings.

}

}

The above is the complete configuration structure of the replication set. The most advanced configuration structure consists of three levels:

_ id 、 members 、 settings .

_ id is the name of the replication set, the same name provided when creating members of the replication set with the-- replSet command option.

Members is an array consisting of a collection that describes each member; this is the member mechanism that should be provided in the rs.add () command when adding a single server to the collection

Settings is also an array, and the settings array contains options that apply to the entire replication set. These options set how replication set members communicate.

XIII. Rollback

Mongodb only supports rollback of data less than 300m. If the data larger than 300m needs to be rolled back or the operation to be rolled back takes more than 30 minutes, it can only be rolled back manually. The following error is reported in the mongodb log: [replica set sync] replSet syncThread: 13410 replSet too much data to roll back

Classics to prevent rollback from happening. The way to do this is to use replicated write concerns (Write Concern) rules to prevent rollback from happening.

If a rollback occurs, a file called database.collection.timestamp.bson is generated in the mongodb data file directory. View the contents of the file using the bsondump tool.

XIV. Read preferences (ReadPreferred)

Read preference refers to how you choose which replication set member to read data from. You can specify 5 modes for the driver to set read preferences.

ReadPreference=primary | primaryPreferred | secondary | secondaryPreferred | nearest

The setReadPreferred () command sets the read preference.

Primary: read data only from the primary server. If the user explicitly specifies to use the tag read preference, the read preference will be blocked. This is also the default read preference.

PrimaryPreferred: reads will be redirected to the primary server; if no primary server is available, reads will be redirected to a secondary server

Secondary: the read will be redirected to the secondary server node. If there is no secondary server node, this option will generate an exception

SecondaryPreferred: reads will be redirected to the secondary server; if there is no secondary server, the reads will be redirected to the primary server. This option corresponds to the old "slaveOK" method

Nearest: reads data from the nearest node, whether it is a primary or secondary server. This option determines which node server to use through network latency.

Write concern settings (Write Concern)

Write concerns are similar to read preferences, which allows you to specify how many nodes the data must be safely submitted to before the write operation is confirmed to be complete.

The pattern of write concerns determines how data is persisted during write operations. The parameter "w" forces the getLastError to wait until the members of the given data have completed the final write operation. The value of w contains the primary node.

Write the 5 patterns of concern:

Wreck0 or indeterminate: one-way write operation. After the write operation is performed, there is no need to confirm the submission status.

Confirm 1 or confirm: the write operation must wait for confirmation from the master server. This is the default behavior.

Whistn or replication set confirmation: the primary server must confirm the write operation. And nMel 1 member must replicate the write operation from the master server. This option is more powerful, but can cause delays.

W=majority: the write operation must be confirmed by the master server, as well as by most members of the collection. While wimpn may cause problems due to system outages or replication delays.

J=true log: you can specify, together with w= write concerns, that the write operation must be written to the log, which is the only way to confirm completion.

Wtimeout: prevent getLastError from waiting, which is the timeout value of the command. If it is not returned after this time, a failure will be returned. The value is measured in milliseconds. If the return fails, the value does not copy the write operation to the "w" member within the specified time.

This operation works only on that connection, and other connections are not limited by the "w" value of the connection.

Db.products.insert (

{item: "envelopes", qty: 100, type: "Clasp"}

{writeConcern: {w: 2, wtimeout: 5000}}

)

Wtimeout# stands for 5 second timeout

Modify default write concerns

Cfg = rs.conf ()

Cfg.settings = {}

Cfg.settings.getLastErrorDefaults = {w: "majority", wtimeout: 5000}

Rs.reconfig (cfg)

Set write wait

Db.runCommand ({"getLastError": 1J w: "majority"})

Or

Db.runCommand ({"getLastError": 1, "w": "majority", "wtimeout": 10000})

That is, indicates that the write operation is copied to most nodes (majority or digits), where the w forces the getLastError to wait until a given number of members have completed the final write operation. Wtimeout means that if the write operation is not returned after this time, a failure prompt is returned (that is, the write operation cannot be copied to the w members within the specified time). GetLastError does not mean that the write operation failed, but that the write operation was not copied to the specified w members within the specified wtimeout time. W limits (controls) the write speed and only blocks operations on this connection. Operations on other connections are not affected.

Use tags in reading preferences and writing concerns (tags)

XVII. Electoral mechanism

1. Whether you can connect with the master node

2. Whether the data of the backup node of the primary node of the desired option is up to date

3. Are there any other higher priority members who can be elected as the primary node

4. If the member elected as the master node can get the vote of the "majority" members in the replica set, it will become the master node, and if only one of the "majority" members veto the election, the election will be cancelled. One veto is equivalent to 10000 yeses.

5. Members who want to become master nodes must use replication to update their data to the latest

XVIII. Data initialization process

1. First, do some preparatory work before recording: select a member as the synchronization source, create an identifier for yourself in the local.me collection, delete the database where the index already exists, and start synchronization in a new state; during this process, all data will be deleted.

2. Then clone, that is, all the records of the synchronous source are copied locally.

3. Then enter the first step of oplog synchronization, and all operations during the cloning process will be recorded in oplog.

4. Next comes the second step of the oplog synchronization process, which is used to record the operations in the first oplog synchronization.

5. By now, the local data should be exactly the same as the dataset of the master node at some point in time, and you can start to create the index.

6. If the data of the current node still lags behind the synchronization source, the last step of the oplog synchronization process is to synchronize all operations during the creation of the index to prevent the member from becoming a backup node.

7. Now that the current member has completed the synchronization of the initialization data and switched to the normal state, the node can become a backup node.

XIX. Settings that mongodb3.0 recommends to enable

Echo never > / sys/kernel/mm/transparent_hugepage/enabled

Echo never > / sys/kernel/mm/transparent_hugepage/defrag

It only works for the time being after executing the above two commands. If the mongod service is restarted, it will fail. Permanent effective rule

Write to / etc/rc.local

That is,

Modify the server hostname name

1. First modify the hostname; of the secondary server and then stop secondary

2. Restart secondary to modify the new hostname

3. Log in to primary

4. Modify the configuration information of the replication set with the rs.reconfig () command

Conf=rs.conf ()

Conf.members[x]. Host='new_address:27017'

Rs.reconfig (conf)

21. Generate keyfile file

Openssl rand-base64 666 > / opt/mongo/conf/MongoReplSet_KeyFile

Chown mongod.mongod / opt/mongo/conf/MongoReplSet_KeyFile

Chmod 600 / opt/mongo/conf/MongoReplSet_KeyFile

This is the end of this article on "how to maintain mongodb replication sets". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please 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.