MongoDB replica Set implementation

MongoDB Replica Set Overview

take a piece from the official MongoDB document: http://docs.mongodb.org/manual/core/replication-introduction/

650) this.width=650; "Src=" http://images.cnitblog.com/blog/288950/201308/11144626- E95b0689174d4727974d39c02fd54a7e.png "/>

The primary node receives all write operations for the client, and the entire replica set will have only one primary node. The MongoDB replica set provides strict consistency. The master node writes all the operations to a capped collection called Oplog (this collection is typically 5% of the disk's remaining space, and different systems may not be the same, see http://docs.mongodb.org /manual/core/replica-set-oplog/), the secondary node replicates Oplog and performs all operations in the Oplog because the execution of the Oplog is idempotent, So the data on the secondary node can remain the same as the primary node, of course, there is a "catch up" process, there will be some lag (lag) sometimes because the network delay or downtime caused from the node can never catch the master node, This is the time for an artificial intervention (resyncing Member of Replica Set) will be mentioned later.

650) this.width=650; "Src=" http://images.cnitblog.com/blog/288950/201308/11144654- F32324ddcdcd4a2d86040cb7dffe137f.png "/>

The default read operation is also the primary node of the walk, and of course the client can choose to read from the secondary node to reduce the pressure on the primary node (which is explained in detail later for read-write separation).

Each node is maintained through the heartbeat mechanism, when the primary node cannot communicate with the other nodes in the cluster for more than 10 seconds, the cluster will choose a secondary from the remaining nodes as primary, the process is called the election (election), Each secondary node has a precedence priority to participate in the poll (or the secondary node with no voting rights), the higher the priority value becomes the primary node (all nodes can have the same priority, and the default value is 1). Election's strategy is not just based on the priority value, it will synthesize many other factors. In short, MongoDB implements the automatic failover through the heartbeat and election mechanisms:

650) this.width=650; "Src=" http://images.cnitblog.com/blog/288950/201308/11144724- B0451f7d670c4acb96a2f5285b45027a.png "/>

It is easy to understand that the replica set requires an odd number of nodes to participate in an election poll (vote). When we restrict only two (or even) nodes in our actual environment because of machine and other reasons, then in order to implement automatic failover introduce another kind of node: Arbitrator (arbiter), the arbitrator only participates in voting does not have the actual data, therefore it is not strict to the physical resource requirement.

650) this.width=650; "Src=" http://images.cnitblog.com/blog/288950/201308/ 11144752-1bcd41d184e94961b6a5f7f92398103c.png "/>

Primary,secondary and Arbiter are mentioned above, and there are several other types of nodes in the entire MongoDB replica cluster, in addition to these three kinds:

• secondary-only: This type of node has a copy of the data as the secondary node, but they are not primary nodes in any situation.

• Hidden: This type of node is not visible to client programs, nor can it be a primary node, but Hidden members can participate in voting.

• Delayed: Members of this type can specify a time to delay synchronizing data from the primary node by setting it artificially. The role of the delayed member is to help the cluster recover from some misoperation, such as an administrator mistakenly deleting a collection. Not quickly spread across the cluster. Therefore the delayed node must not be a primary node (priority is 0) and is hidden.

• non-voting: This is the secondary node with no voting rights mentioned above. This type of node is typically required when the number of cluster nodes exceeds 12.

building a simple replica set

Master: 192.168.1.100

From: 192.168.1.101,192.168.1.102

1. First the MongoDB is installed (we use RPM installation).

MongoDB default port is: 27017

2. Modify the two slave node configuration files

Service Mongod Stop vim/etc/mongod.conf

Uncomment Replset, set its name, and add a Replindexprefetch item. As follows:

650) this.width=650; "Src=" https://s5.51cto.com/wyfs02/M01/8F/0D/wKiom1jSM-jRLhx4AAAr4CAnUDU526.jpg-wh_500x0-wm_ 3-wmp_4-s_1062083605.jpg "title=" 1.jpg "alt=" Wkiom1jsm-jrlhx4aaar4canudu526.jpg-wh_50 "/>

Restart Service:

Service Mongod Start

3. Log in to the main node command line

Mongo

>rs.status () {"Startupstatus": 3, "info": "Run Rs.initiate (...) If not yet do for the set "," OK ": 0," errmsg ":" Can ' t get local.system.replset config from self or any seed (yconfig) "}

To 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}

The MONGO client uses command Rs.initiate () to start a new replica set.

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

View replica set status using the Rs.status () command

Replica set Add Member

To add members of the replica set, we need to use multiple servers to start the MONGO service. Enter the MONGO client and use the Rs.add () method to add members of the replica set.

Grammar

The basic syntax format for 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")--default 27017 do not specify {"OK": 1}testset:primary> rs.add ("192.168.1.102") {"OK" : 1}

At this point, view the replica set status:

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: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: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 master node and insert new data:

Testset:primary> show Dbs;admin (empty) local 6.075gbtestset:primary> use testswitched to DB TESTTESTSET:PRIMARY&G T Show Dbsadmin (empty) local 6.075gbtestset:primary> Db.test.insert ({"Name": "Rookie Tutorial"}) Writeresult ({"ninserted": 1}) Testset:primary> show Dbsadmin (empty) local 6.075GBtest 0.078GB

To view information from a node:

Testset:secondary> show Dbs;admin (empty) local 6.075GBtest 0.078gbtestset:secondary> db.test.find () {"_id": OBJ Ectid ("58d231485934aa983f070c99"), "name": "Rookie Tutorial"}

Problems and Solutions:
1. Initializing the replica set times wrong:

>rs.initialte () {.... "ErrMsg" "couldn ' t Initiate:can ' t find self in the Replset config", "OK": 0 ....}

FIX: Edit the Hosts file to add host name resolution, and then reinitialize the replica set.

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

2. Add replica set member times wrong:

Testset:primary> Rs.add ("192.168.1.101:27017") {"errmsg": "Exception:need most members up to reconfigure, not ok:192 .1.101:27017 "," code ": 13144," OK ": 0}

Workaround: Because bind is bound to 127.0.0.1 IP information from the node configuration file, it cannot add a 192-port IP to comment out its bind.

650) this.width=650; "Src=" https://s1.51cto.com/wyfs02/M02/8F/0B/wKioL1jSPNqCiBMSAAAvCogQHmA888.jpg-wh_500x0-wm_ 3-wmp_4-s_4119458428.jpg "title=" 123.jpg "alt=" Wkiol1jspnqcibmsaaavcogqhma888.jpg-wh_50 "/>

3. Add the completion member, when viewing the replica set status, the node always displays as: "statestr": "UNKNOWN "

650) this.width=650; "Src=" https://s1.51cto.com/wyfs02/M00/8F/0B/wKioL1jSPZzTpvE1AACPnUcv2Ao754.jpg-wh_500x0-wm_ 3-wmp_4-s_3965650403.jpg "title=" 3.jpg "alt=" Wkiol1jspzztpve1aacpnucv2ao754.jpg-wh_50 "/>

Workaround: The problem is because rs.initiate () defaults to setting the host key of the primary to the hostname of the machine, as follows:

650) this.width=650; "Src=" https://s3.51cto.com/wyfs02/M02/8F/0B/wKioL1jSPk7hn8YNAABcLqNWlSE164.jpg-wh_500x0-wm_ 3-wmp_4-s_2413500151.jpg "title=" 4.jpg "alt=" Wkiol1jspk7hn8ynaabclqnwlse164.jpg-wh_50 "/>

1) You can edit both the hosts file from the node to add the master node hostname and IP information, such as:

[Email protected] ~]# 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 host name of the primary to an IP address:

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

MongoDB replica Set implementation