Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Mongodb replica set implementation

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

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

Overview of MongoDB replica set

The following pictures are taken from the official MongoDB document: http://docs.mongodb.org/manual/core/replication-introduction/

The Primary node receives all write operations from the client, and there will be only one primary node for the entire replica set. MongoDB replica sets provide strict consistency. The master node writes all operations to a capped collection called oplog (the size of this collection is generally 5% of the remaining disk space, and different systems may be different. For more information, see http://docs.mongodb.org/manual/core/replica-set-oplog/), where secondary nodes copy oplog and perform all operations in oplog. Because the execution of oplog is idempotent, the data on secondary nodes can be kept the same as primary nodes. Of course, there is a process of "catch up", and there will be a certain Lag. Sometimes the slave node can never catch up with the master node due to network delay or downtime, which requires human intervention (we will talk about Resyncing Member of Replica Set later).

By default, all read operations are also done on the primary node. Of course, the client can choose to read from the secondary node to reduce the pressure on the master node (more on the separation of read and write later).

Each node maintains contact through the heartbeat mechanism. When the master node is unable to communicate with other nodes in the cluster for more than 10 seconds, the cluster will select a secondary from the remaining nodes as the primary. This process is called election. Each secondary node has a priority priority to vote (there can also be secondary nodes without voting rights). The higher the priority value, the more priority it takes to become the primary node (all nodes can have the same priority, and the default value is 1). Election's strategy is not only based on priority values, but also integrates many other factors. In short, MongoDB implements automatic Failover through heartbeat and election mechanisms:

It is easy to understand that the replica set requires an odd number of nodes to vote in the election (vote). When there are only two (or even) nodes in our real environment because of machines and other reasons, another kind of node is introduced in order to implement Automatic Failover: arbiter, the arbitrator only participates in the vote and does not own the actual data, so it is not strict with physical resources.

Primary,secondary and arbiter have been mentioned above. There are several other types of nodes in the entire MongoDB replica cluster besides these three types of nodes:

Secondary-Only: this type of node has the same copy of data as the secondary node, but they cannot be primary nodes under any circumstances.

Hidden: this type of node is invisible to the client program and cannot be a primary node, but Hidden members can vote in the election.

Delayed: members of this type can specify a time to delay synchronizing data from the primary node by artificially setting it. The role of Delayed members is to help the cluster recover from some misoperation, such as an administrator mistakenly deleting a collection. It will not spread rapidly to the whole cluster. Therefore, the Delayed node must not be a primary node (priority is 0) and be Hidden.

Non-Voting: this is the secondary node mentioned above that has no right to vote. This type of node is generally needed when the number of cluster nodes exceeds 12.

The construction of simple copy set

Master: 192.168.1.100

From: 192.168.1.101192.168.1.102

1. First you have finished installing mongodb (we installed it using rpm).

The default port of mongodb is: 27017

two。 Modify two slave node configuration files

Service mongod stop vim / etc/mongod.conf

Uncomment the replSet, set its name, and add the replIndexPrefetch entry. It is as follows:

Restart the service:

Service mongod start

3. Log in to the command line of the primary node

Mongo > rs.status () {"startupStatus": 3, "info": "run rs.initiate (...) if not yet done for the set", "ok": 0, "errmsg": "can't get local.system.replset config from self or any seed (YCONFIG)"}

Start a new replica set

> rs.initiate () {"info2": "no configuration explicitly specified-- making one", "me": "Centos:27017", "info": "Config now saved locally. Should come online in about a minute" ok ": 1}

Use the command rs.initiate () on the Mongo client to start a new replica set.

We can use rs.conf () to view the configuration of the replica set

To view the status of a replica set using the rs.status () command

Copy set add member

To add members of the replica set, we need to use multiple servers to start the mongo service. Go to the Mongo client and use the rs.add () method to add members of the replica set.

Grammar

The basic syntax format of the rs.add () command is as follows:

> rs.add (Host_NAME:PORT)

Add two slave node members:

TestSet:PRIMARY > rs.add ("192.168.1.101")-by default 27017 do not specify {"ok": 1} testSet:PRIMARY > rs.add ("192.168.1.102") {"ok": 1}

At this point, view the status of the replica set:

TestSet:PRIMARY > rs.status () {"set": "testSet", "date": ISODate ("2017-03-22T07:58:26Z"), "myState": 1, "members": [{"_ id": 0, "name": "Centos:27017", "health": 1, "state": 1, "stateStr": "PRIMARY", "uptime": 1293, "optime": Timestamp (1490168420, 1) "optimeDate": ISODate ("2017-03-22T07:40:20Z"), "electionTime": Timestamp (1490168213, 11), "electionDate": ISODate ("2017-03-22T07:36:53Z"), "self": true}, {"_ id": 1, "name": "192.168.1.101 id 27017", "health": 1, "state": 2, "stateStr": "SECONDARY", "uptime": 1146, "optime": Timestamp (1490168420, 1) "optimeDate": ISODate ("2017-03-22T07:40:20Z"), "lastHeartbeat": ISODate ("2017-03-22T07:58:25Z"), "lastHeartbeatRecv": ISODate ("2017-03-22T07:58:25Z"), "pingMs": 1, "syncingTo": "Centos:27017"}, {"_ id": 2, "name": "192.168.1.102 22T07:40:20Z 27017", "health": 1, "state": 2, "stateStr": "SECONDARY" "uptime": 1086, "optime": Timestamp (1490168420, 1), "optimeDate": ISODate ("2017-03-22T07:40:20Z"), "lastHeartbeat": ISODate ("2017-03-22T07:58:25Z"), "lastHeartbeatRecv": ISODate ("2017-03-22T07:58:24Z"), "pingMs": 1, "lastHeartbeatMessage": "syncing to: Centos:27017", "syncingTo": "Centos:27017"], "ok": 1}

Test:

Create a new library on the primary node and insert the new data:

TestSet:PRIMARY > show dbs;admin (empty) local 6.075GBtestSet:PRIMARY > use testswitched to db testtestSet:PRIMARY > show dbsadmin (empty) local 6.075GBtestSet:PRIMARY > db.test.insert ({"name": "Rookie course"}) WriteResult ({"nInserted": 1}) testSet:PRIMARY > show dbsadmin (empty) local 6.075GBtest 0.078GB

View slave node information:

TestSet:SECONDARY > show dbs;admin (empty) local 6.075GBtest 0.078GBtestSet:SECONDARY > db.test.find () {"_ id": ObjectId ("58d231485934aa983f070c99"), "name": "Rookie tutorial"}

Problems and Solutions:

1. Error initializing copy set Times:

> rs.initialte () {.... "errmsg", "couldn't initiate: can't find self in the replset config", "ok": 0.}

Solution: edit the hosts file to add host name resolution, and then reinitialize the replica set.

[root@Centos ~] # vim / etc/hosts127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6127.0.0.1 Centos

two。 Add a copy of the album member Times error:

TestSet:PRIMARY > rs.add ("192.168.1.101 errmsg 27017") {"errmsg": "exception: need most members up to reconfigure, not ok: 192.1.101 need most members up to reconfigure 27017", "code": 13144, "ok": 0}

Fix: because bind binds the ip information to 127.0.0.1 from the node configuration file, the 192side ip cannot be added and its bind is commented out.

3. After the member is added, the node always displays such as "stateStr": "UNKNOWN" when viewing the status of the replica set

Solution: the reason for the problem is that rs.initiate () sets the host key of primary to the hostname of the machine by default, as follows:

1) you can edit the hosts file of two slave nodes to add the host name and Ip information of the master node, such as:

[root@RedHat-1 ~] # vim / etc/hosts127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6192.168.1.100 Centos

2) you can change the hostname of primary to IP address:

Cfg = rs.conf () cfg.members [0] .host = "192.168.1.100 cfg.members 27017" rs.reconfig (cfg)

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report