MongoDB Replica Set

Brief introduction

MongoDB Replication (replication) is the process of synchronizing data across multiple servers. The master node records all operations on it, oplog the primary node periodically from the node, and then performs these operations on its own copy of the data, ensuring that the data from the node is consistent with the primary node. Replication provides redundant backups of data and stores copies of data on multiple servers, improving the availability of data and ensuring data security. Replication also allows you to recover data from hardware failures and service outages.

The replica set (replica set) is a new feature from MongoDB 1.6 that is more powerful than replication and adds automatic failover and auto-repair of member nodes, with data that is exactly the same across each db. The structure of the Replica sets is similar to a cluster, which can be used as a cluster, because it does the same thing as the cluster implementation, and if one node fails, the other node immediately takes over the business without any downtime.

Tip: For MongoDB related core theory knowledge, suggest to see corresponding documents and books, I do not do the corresponding introduction here (because the theory of things written too laborious).

Installation

Hint: This environment is 3 host environment, IP is 192.168.58.128 (PRIMARY), 192.168.58.129 (secondary), 192.168.58.130 (arbiter) respectively;

First, install MongoDB

1.1 Installing MongoDB

Download:https://www.mongodb.org/dl/linux/x86_64-rhel70;

mkdir /data
tar zxf mongodb-linux-x86_64-rhel70-3.2.0.tgz 
mv mongodb-linux-x86_64-rhel70-3.2.0 /data/mongodb-3.2.0
mkdir /data/mongodb-3.2.0/{data,conf,logs}

1.2 Configuring MongoDB

Close the transparent page first, since the CENTOS6 version introduced transparent Huge pages (THP), which is enabled by default from the CentOS7 version. Although THP is intended to improve memory performance, some database vendors recommend that you turn off THP directly (such as Redis and MongoDB), which may cause performance degradation.

# See if Enabled

[[email protected] ~]# cat /sys/kernel/mm/transparent_hugepage/defrag
[always] madvise never
[[email protected] ~]# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

# Disable the HTP feature

Add the following to the "/etc/rc.d/rc.local" file, and remember to perform "chmod +x/etc/rc.d/rc.local".

# disable THP(Transparent Huge Pages)
echo never >> /sys/kernel/mm/transparent_hugepage/enabled
echo never >> /sys/kernel/mm/transparent_hugepage/defrag

# Create a KeyFile file

openssl rand -base64 756 > /data/mongodb-3.2.0/conf/mongodb_authkey
chmod 600 /data/mongodb-3.2.0/conf/mongodb_authkey
scp /data/mongodb-3.2.0/conf/mongodb_authkey 192.168.58.129:/data/mongodb-3.2.0/conf/
scp /data/mongodb-3.2.0/conf/mongodb_authkey 192.168.58.130:/data/mongodb-3.2.0/conf/

Tips:

KeyFile files are indispensable for replica sets, and communication between them depends on this. However, I do not seem to need this configuration when testing Yum installation, however, in the case of a binary installation, authentication fails if KeyFile is missing.

# Configure MongoDB configuration file

[[email protected] ~]# cat /data/mongodb-3.2.0/conf/mongodb.conf 
bind_ip=192.168.58.128
port=5336
dbpath=/data/mongodb-3.2.0/data
logpath=/data/mongodb-3.2.0/logs/mongodb.logs
logappend=true
replSet=mongodb01
fork=true
auth=true
directoryperdb=true
maxConns=8000
cpu=true
oplogSize=8000

Tip: It is recommended that you turn off the "auth=true" parameter first, because if you turn on the configuration item, you need to certify it during the initial addition of the replica set. However, you do not have the relevant user and password at this time, so you cannot pass MongoDB authentication. Therefore, disable this parameter first and then turn on the authentication function after adding the new user. In one of the closed on the line, I chose here to operate on the 192.168.58.128 (PRIMARY) host.

1.3 Start MongoDB

/data/mongodb-3.2.0/bin/mongod-f/data/mongodb-3.2.0/conf/mongodb.conf

Third, configure the replica set

3.1 Creating an administrative user

/data/mongodb-3.2.0/bin/mongo 192.168.58.128:5336
> rs.initiate()
{
	"info2" : "no configuration specified. Using a default configuration for the set",
	"me" : "192.168.58.128:5336",
	"ok" : 1
}
mongodb01:OTHER> db.createUser(  
   {  
     user: "admin",  
     pwd: "[email protected]",  
     roles: [ { role: "root", db: "admin" } ]  
   }  
) 
mongodb01:PRIMARY> exit

3.2 Open user authentication and restart service

Tip: During routine maintenance, MongoDB shutdown recommends using KILL-2 instead of using kill-9.

3.3 Configuring the MongoDB replica set

/data/mongodb-3.2.0/bin/mongo 192.168.58.128:5336-u admin-p--authenticationdatabase Admin

# Add Replica set

mongodb01:PRIMARY> show dbs
admin 0.000GB
local 0.000GB
mongodb01:PRIMARY> rs.add("192.168.58.129:5336")
mongodb01:PRIMARY> rs.addArb("192.168.58.130:5336")
mongodb01:PRIMARY> rs.status()

# Test Replication

When inserting data

for (var i = 0; i <100000; i ++) db.test.insert ({title: ‘MongoDB Tutorial’ + i,
      description: ‘MongoDB is a Nosql database’ + i,
      by: ‘Novice Tutorial’ + i,
      url: ‘http://www.runoob.com’,
      tags: [‘mongodb’, ‘database’, ‘NoSQL’],
      likes: 100
  })

See if data is consistent in primary and secondary

Db.test.count ()

# Test Switch

Kill primary and view status in secondary

mongodb01:PRIMARY> rs.status()
{
	"set" : "mongodb01",
	"date" : ISODate("2017-09-20T02:15:23.819Z"),
	"myState" : 1,
	"term" : NumberLong(3),
	"heartbeatIntervalMillis" : NumberLong(2000),
	"members" : [
		{
			"_id" : 0,
			"name" : "192.168.58.128:5336",
			"health" : 0,
			"state" : 8,
			"stateStr" : "(not reachable/healthy)",
			"uptime" : 0,
			"optime" : {
				"ts" : Timestamp(0, 0),
				"t" : NumberLong(-1)
			},
			"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
			"lastHeartbeat" : ISODate("2017-09-20T02:15:21.902Z"),
			"lastHeartbeatRecv" : ISODate("2017-09-20T02:01:16.163Z"),
			"pingMs" : NumberLong(0),
			"lastHeartbeatMessage" : "Connection refused",
			"configVersion" : -1
		},
		{
			"_id" : 1,
			"name" : "192.168.58.129:5336",
			"health" : 1,
			"state" : 1,
			"stateStr" : "PRIMARY",
			"uptime" : 69990,
			"optime" : {
				"ts" : Timestamp(1505872886, 2),
				"t" : NumberLong(3)
			},
			"optimeDate" : ISODate("2017-09-20T02:01:26Z"),
			"electionTime" : Timestamp(1505872886, 1),
			"electionDate" : ISODate("2017-09-20T02:01:26Z"),
			"configVersion" : 3,
			"self" : true
		},
		{
			"_id" : 2,
			"name" : "192.168.58.130:5336",
			"health" : 1,
			"state" : 7,
			"stateStr" : "ARBITER",
			"uptime" : 69615,
			"lastHeartbeat" : ISODate("2017-09-20T02:15:23.303Z"),
			"lastHeartbeatRecv" : ISODate("2017-09-20T02:15:21.905Z"),
			"pingMs" : NumberLong(0),
			"configVersion" : 3
		}
	],
	"ok" : 1
}

You can see that the original secondary has become PRIMARY. At this point we are inserting data into the primary;

description: ‘MySQL is a relational database’ + i,
      by: ‘Novice Tutorial’ + i,
      url: ‘http://www.runoob.com’,
      tags: [‘MySQL’, ‘database’, ‘SQL’],
      likes: 100
  })

Restart the "PRIMARY" just killed to see if the data is synchronized

mongodb01:SECONDARY> db.getMongo().setSlaveOk()
mongodb01:SECONDARY> db.test.count()
200000

Finally, in giving some suggestions in the production environment, Restarting the node after a node has been down for a period of time (depending on the amount of data and downtime of the cluster) causes all nodes in the cluster to become secondary and unable to write (if the application does not set the appropriate readreference may not be able to read) 。

So the official recommended minimum replica set should also have a primary node and two secondary nodes. A replica set of two nodes does not have a true failover capability.

Finally, MongoDB related articles, reference http://www.cnblogs.com/zhanjindong/p/3268963.html, the article is quite good.

MongoDB Replica Set