MongoDB Maintenance Replica Set

In each MongoDB (version 3.2.9) instance, there is a local database that stores information and local data for Replication processes. The local database is characterized by the fact that data and collections located in the local database are not copied to other MongoDB instance by the Replication process. If some collection and data on the instance are not scheduled to be copied to other MongoDB Instance, these collection and data can be stored in the local database.

The MongoDB shell provides a global variable RS, which is a wrapper for database commands (wrapper) for maintaining replica Set.

One, the configuration of the Replica set

1. View the configuration information for the replica set

MongoDB stores the configuration information for the replica set in the Local.system.replset collection, in the same replica All members in the set Local.system.replset are the same, cannot modify the collection directly, must be initialized by Rs.initiate (), reconfigured by Rs.reconfig (), and replica set Adding or removing members modifies the configuration information for the replica set accordingly.

Rs.config () use Localdb.system.replset.find ()

Configuration information Important information has two main parts: the ID value of the Replica set and the member array.

{_id: "Replica set name", Members: [    {      _id: <int>,      host: "Host:port",      arbiteronly: <boolean      buildindexes: <boolean>,      hidden: <boolean>, priority      : <number>,      Slavedelay: <int>,      votes: <number>    },    ...  ],...}

Configuration documents for Members:

Priority: Indicates that a member is elected to the primary node, the default value is 1, the value range is from 0 to 100, and priority is set to 0 with a special meaning: the member with priority 0 can never be a primary node. Replica set, the highest priority member, will be elected as the primary node, as long as it satisfies the conditions.

Hidden: Configures a member to be a hidden member, requiring a priority of 0. The client does not send requests to the hidden members, so the hidden members do not receive the request from the client.

slavedelay: The unit is seconds, the secondary member is configured to delay the backup node, and a priority of 0 is required, indicating that the member has a time lag specified by the primary member to synchronize the write operations on the primary to local. For data read consistency, the hidden of the deferred backup node should be set to true to prevent users from reading data that is significantly lagged. Delayed members maintain a copy of the data that reflects the state of the the the data at some time in the past.

votes: The valid value is 0 or 1, the default value is 1, and if votes is 1, the member (voting member) has permission to elect primary members. In a replica set, there are up to 7 members, and the value of the votes property is 1.

arbiteronly: Indicates that the member is the arbiter, and the only function of arbiter is to participate in the election, whose votes attribute is 1,arbiter does not save the data and does not provide services to the client.

buildindexes: Indicates that the index is actually created on the member, the property cannot be modified, and can only be set when the member is added. If a member is simply a backup and does not receive a client request, setting the member to not create index can improve the efficiency of data synchronization.

2, reconfigure replica Set

For replica set reconfiguration, you must connect to the primary node, and if no node in replica set is elected as primary, you can use force option (rs.reconfig: true}), forcing the replica set to be reconfigured on the secondary node.

The force parameter allows a reconfiguration command to being issued to a non-primary node. If set as {force:true}, this forces the replica set to accept the new configuration even if a majority of the members a Re not accessible. Use with caution, as this can leads to rollback situations.

Example, in the primary node, reconfigure the member's Priority attribute (precedence).

CFG = rs.conf () cfg.members[0].priority = 1cfg.members[1].priority = 1cfg.members[2].priority = 5rs.reconfig (CFG)

3, add members

3.1, which adds a member using the default configuration

--Add a member to store the data
Rs.add ("Host:port")

--Add a arbiter for the election

Rs.add ("Host:port", True)

3.2, adding members using the configuration document

example, add a hidden node for replica set to delay backup, lag primary node 1hour, the node does not participate in voting, and does not create INDEX, just as a data backup.

Rs.add ({_id:4, Host: "Host:port", priority:0, Hidden:true, slavedelay:3600, votes:0, Buildindexes:true, ARBITERONLY:FA LSE})

4, deleting members

Rs.remove ("host")

5, replica set reconfiguration, ability to add members, delete members, and can modify the properties of members at the same time

Second, operate on the members of the replica set

1, freezes the current member, so that the current member is not eligible to become a primary within a specified time, that is, the current member maintains secondary identity for a certain period of time

Makes the current replica set member ineligible to become primary for the period specified.

Rs.freeze (seconds)

2, forcing the Primary node to degenerate into a secondary node

Rs.stepdown () causes the current primary node to degenerate into a secondary node and fires an event for an election primary. This function causes the current primary node to be a primary node within a specified time. In a certain time period, if the secondary node satisfies the condition, then the secondary node is elected as primary node, if no secondary node satisfies the condition, then the original primary node participates in the election. The Stepdown function makes the primary node degenerate into secondary and cannot participate in the election for a period of time.

Forces the primary of the replica set to become a secondary, triggering an election for primary. The method steps down the primary for a specified number of seconds; During this period, the Stepdown member are ineligible from becoming primary.

Rs.stepdown (Stepdownsecs, Secondarycatchupperiodsecs)

3, forces the current member to synchronize data from the specified member

Rs.syncfrom ("Host:port");

4, so that the current secondary node can read the data

By default, the secondary node is not able to read data

Rs.slaveok ()

Third, view the status of the replica set

Set field: Replica Set's name

STATESTR: Description information for member status

Name: The member's host and port

Syncto: The member synchronizes data from which member, you can use Rs.syncfrom () to force the synchronized path to synchronize the data from the specified Target member.

{    "set": "Rs0",    "MyState": 1,    "Heartbeatintervalmillis": Numberlong (+),    "members": [         {            "_id": 0,            "name": "cia-sh-05:40004",            "health": 1,            "state": 2,            "STATESTR": "Secondary",            "uptime ": 240973,            " Optime ": {                " ts ": Timestamp (1473336939, 1),                " T ": Numberlong (5)            },            " Optimedate ": Isodate ("2016-09-08t12:15:39.000z"),            "Lastheartbeat": Isodate ("2016-09-10t04:39:55.041z"),            " Lastheartbeatrecv ": Isodate (" 2016-09-10t04:39:56.356z "),            " Pingms ": Numberlong (0),            " syncingto ":" cia-sh-06:40001 "        }, ...    ]}

Third, the operation log of Replica set

The replication of MongoDB is actually a copy based on the operation log (operation log). The entire process of the Replication process is: Replication records the writes performed in the primary node to the Oplog collection, and the secondary member reads the primary collection of Oplog members. Redo (Redo) writes are recorded in the Oplog, and finally, the Replica set of each member achieves data consistency.

The operations recorded in the Oplog collection are based on a single doc, that is, if a command affects only one doc, then replication inserts an action command into the Oplog collection, and if one command affects more than one doc, Then replication splits the command into multiple equivalent operations commands, each of which affects only one doc, and eventually inserts multiple operations commands into the Oplog collection.

1,oplog Collection

The Oplog collection is a special fixed set that stores the operations log of the primary node, and each replica set member has a oplog copy: local.oplog.rs, which is stored in each member's local database. Each member of the Replica set has a Oplog collection that stores the operation records of the current node, and other members can synchronize data from the Oplog of any one member.

The Oplog (Operations log) is a special capped collection this keeps a rolling record of all operations that modify the DA Ta stored in your databases. MongoDB applies database operations on the primary and then records the operations on the primary ' s oplog. The secondary members then copy and apply these operations in an asynchronous process. All replica set members contain a copy of the Oplog, in the Local.oplog.rs collection, which allows them to maintain the C urrent state of the database.

Size of the 2,oplog

The Oplog collection is a fixed set whose size is fixed and MongoDB creates a default size of Oplog when the member of the replica set is first started. In MongoDB 3.2.9, the default storage engine for MongoDB is Wiredtiger, in general, the default size of Oplog is 5% of the disk free space on which the data file resides, and the minimum is no less than 990 MB. Maximum no more than a few gigabytes.

3, modify the size of the Oplog

The process of modification is divided into three main steps:

• Restart Mongod in stand-alone mode
• After startup, recreate the Oplog and keep the last record as a seed
• Restart Mongod in replica set mode

The detailed process is:

Step1: Restart in standalone mode Mongod

For primary members, first call the Stepdown function, forcing the primary member to transition to the secondary member

Rs.stepdown ()

For secondary members, call the Shutdownserver () function, close Mongod

Use admin db.shutdownserver ()

Start the Mongod instance, do not use the Replset parameter

Mongod--port 37017--dbpath/srv/mongodb

Step2: Create a new Oplog

Be prepared, backup oplog files

Mongodump--db local--collection ' oplog.rs '--port 37017

Saves the last valid record in Oplog to the Temp collection as the seed for the new Oplog

Use Localdb.temp.drop () Db.temp.save (Db.oplog.rs.find ({}, {ts:1, h:1}). Sort ({$natural:-1}). Limit (1). Next ())

Db.oplog.rs.drop ()

Rebuilds the new Oplog collection and saves a record in the Temp collection to Oplog, in the unit of byte

Db.runcommand ({create: "oplog.rs", Capped:true, Size: (2 * 1024x768 * 1024x768)}) Db.oplog.rs.save (Db.temp.findOne ())

Step3: Starting the Mongod,replset parameter in replica set mode the correct replica set name must be set

Db.shutdownserver () Mongod--replset Rs0--dbpath/srv/mongodb

Third, view Mongod's boot log

In the Local.startup_log collection, the storage Mongod log on every boot

Reference Documentation:

The local Database

Replica Set Configuration

Replica Set Oplog

Change the Size of the Oplog

MongoDB Maintenance Replica Set