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

In this issue, the editor will bring you about how the data replication in MongoDB is realized. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Data synchronization mode

The replication function in MongoDB is mainly realized by using the operation log oplog.rs. Oplog.rs contains every write operation of the master node. Oplog.rs is a fixed collection of local databases in the master node, which can be viewed by the following command:

Use localshow tables

As follows:

The backup node knows which data to copy by querying this collection. At the same time, each backup node maintains its own oplog.rs, and its own oplog.rs is used to record every operation of copying data from the primary node. In this way, each backup node can be provided to other members as a data source. If a backup node dies while in use, when it is rebooted, Automatically synchronizes from the last operation of oplog.rs.

As we have said earlier, oplog.rs is a fixed collection. We can use the command db.getCollection ('oplog.rs'). Stats () to view the properties of this fixed collection, including the size of the collection. The result of the execution is as follows:

{"ns": "local.oplog.rs", "size": 18170305, "count": 177443, "avgObjSize": 102,102, "storageSize": 5902336, "capped": true, "max":-1, "maxSize": 1038090240, "sleepCount": 0, "sleepMS": 0,}

Since it is a fixed collection, the size of the data that can be saved in it is limited. In general, the growth rate of oplog.rs usage space is almost the same as the rate at which the system processes write requests. For example, if the master node processes 1KB write requests every minute, oplog.rs may also write 1KB operation logs within one minute, but if the master node executes the command of batch deletion, such as the following:

Db.c1.deleteMany ({x: {$type:1}})

At this point, each affected document will generate a log in oplog, and the log in oplog.rs will increase rapidly.

Member statu

So far, we have learned that there are two kinds of member states, one is PRIMARY and the other is SECONDDARY. The acquisition of member status needs to be maintained by heartbeat. Each member in the replica set sends a heartbeat request to other members every two seconds to check the status of members. The main states of members are as follows:

STARTUP

When the member in the replica set is in this state when it is started, MongoDB will load the replica set configuration of the member. After the configuration is loaded successfully, it will enter the state of STARTUP2.

STARTUP2

The entire initialization synchronization process is in this state.

RECOVERING

This state is derived from the STARTUP2 state, when the member is functioning normally, but the read request cannot be processed at this time.

ARBITER

This is the state of the arbitrator.

DOWN

When a normally functioning member cannot be accessed, the member is in the DOWN state.

UNKNOWN

If a member cannot reach any other member, the member is in the UNKNOWN state. For example, if we use the rs.add () method to add a member that does not exist, the member's state is UNKNOWN.

REMOVED

This state occurs when a member is removed from the replica set.

ROLLBACK

If a member is doing a data rollback, it is in the ROLLBACK state, and after the rollback ends, it transitions to the RECOVERING state.

FATAL

This is the state when a member makes an irreparable error and stops trying to return to normal.

Transfer from primary node to backup node

You can turn the primary node into a backup node with the following command:

Rs.stepDown ()

After the primary node becomes a backup node, the new primary node will be elected, and you can view the new primary node through rs.status ().

Rs.status () method

We have used the rs.status () method many times before. The rs.status () method lists the meaning of each backup node. Let's look at the meaning of these parameters. Let's first list a sample return value of the rs.status () method:

{"members": [{"_ id": 1, "name": "192.168.248.135 name", "health": 1, "state": 2, "stateStr": "SECONDARY", "uptime": 241, "optime": {"ts": Timestamp (1509881297, 1) "t": NumberLong (16)}, "optimeDurable": {"ts": Timestamp (1509881297, 1), "t": NumberLong (16)}, "optimeDate": ISODate ("2017-11-05T11:28:17Z"), "optimeDurableDate": ISODate ("2017-11-05T11:28:17Z") "lastHeartbeat": ISODate ("2017-11-05T11:28:18.073Z"), "lastHeartbeatRecv": ISODate ("2017-11-05T11:28:18.769Z"), "pingMs": NumberLong (0), "syncingTo": "192.168.248.136 05T11:28:18.073Z 27017", "configVersion": 15}, {"_ id": 3 "name": "192.168.248.136 state 27017", "health": 1, "state": 1, "stateStr": "PRIMARY", "uptime": 250, "optime": {"ts": Timestamp (1509881297, 1), "t": NumberLong (16)} OptimeDate: ISODate ("2017-11-05T11:28:17Z"), "electionTime": Timestamp (1509881276, 1), "electionDate": ISODate ("2017-11-05T11:27:56Z"), "configVersion": 15, "self": true}]}

1.stateStr is used to describe the status of the current node.

2.uptime indicates the time that can be experienced from the member to the present.

3.optimeDate represents the time when the last operation occurred in each member's oplog.

4.lastHeartbeat indicates the last time the current server received a heartbeat from another member.

5.pingMs represents the average time it takes for a heartbeat to reach a member from the current server.

6.syncingTo represents the synchronized data source.

7.health indicates whether the server is reachable, 1 for reachable and 0 for unreachable.

Replication chain problem

When replicating data, you can either copy directly from the master node or start from the backup node. Replication from the backup node can form a replication chain. If you want to prohibit the replication chain, that is, all data is copied from the master node, you can set it through the chainingAllowed attribute. Specific steps are as follows:

Config=rs.config () config.settings.chainingAllowed=falsers.reconfig (config) above is how the data replication in MongoDB shared by Xiaobian is realized. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.