MongoDB Maintenance Replica Set

In each MongoDB instance, there is a local database that stores information about the Replication process and local data. 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, cannot modify the collection directly, must be initialized through Rs.initiate (), reconfigured by Rs.reconfig (), Adding or removing members to the replica set modifies the configuration information of 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"  [    {      _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).

= rs.conf () cfg.members [0] = 1 cfg.members [1] = 1 cfg.members [2] = 5 rs.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 the specified time.

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

Rs.freeze (seconds)

2, plotting primary node abdication

Rs.stepdown () triggers an election primary event so that the current primary node cannot become a primary node within a specified time. If the secondary node satisfies the condition, then the primary node is dismissed as the primary node, and if no secondary node satisfies the condition, the node continues to be the primary node.

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 (2000),    "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

MongoDB's replication is actually based on operations log replication, the primary node logs the execution of the write to Oplog, replication synchronizes Primary's oplog to the other members, The other member redo (redo) writes that are recorded in Oplog, and finally, the Replica set of the individual members to achieve data consistency.

In the local database, the collection local.oplog.rs is a fixed-size collection that stores the primary operation log (Oplog).
Local.oplog.rs is the capped collection that holds the Oplog. You set it size at creation using the OPLOGSIZEMB setting. To resize the oplog after replica set initiation with the change the Size of the Oplog procedure.

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

MongoDB Maintenance Replica Set