Configuring a MongoDB Replication set

What is a replication set?

A replica set is an additional copy of the data that is the process of synchronizing data across multiple servers, providing redundancy and increasing data availability through a replica set to recover from hardware failures and interrupted services.
The benefits of a copy set are as follows:

• Make your data more secure
• High data Availability (24*7)
• Disaster recovery
• Maintenance without downtime (e.g. backup, index rebuild, failover)
• Read scaling (extra copy read)
• The replica set is transparent to the application

How replication sets work

A copy set of MongoDB requires at least two nodes. One is the master node (Primary), which handles the client's request, and the rest is the slave node (secondary), which replicates the data on the master node.
MongoDB each node common collocation method is: a master one from or a master many from. The master node records all operations on it to Oplog, and the nodes periodically poll the master node for these operations, ensuring that the data from the node is consistent with the primary node.
The client writes data to the primary node, reads the data from the node, and the master node interacts with the data from the node to ensure data consistency. If one of the nodes fails, the other nodes will immediately connect to the business without downtime.
The replication set features the following:

• n Nodes of a cluster
• Any node can be used as the master node
• All write operations are on the primary node
• Auto Fail-Over
• Automatic recovery

MongoDB replica set deployment creates multiple instances

How to create a multi-instance, in my previous blog has been written, you can refer to the Yum installation MongoDB and database management each instance should create a data file directory (MONGO) and log files (Mongod.log), while modifying the configuration file should be careful to modify the use of different port numbers when making a copy set, we need to modify one parameter, replication the parameter value, and ensure that the parameter value of multiple instances is consistent according to the project requirements, an additional three instances are created, plus one instance of the original, with a total of four instances.
When I was doing the experiment, I found that the format of the configuration file in MongoDB is also strict, and you should pay special attention when modifying the replication parameter value.

replication:  replSetName: chenrs      //该行内容需在行首空出两个空格，不空格或者多空格都会导致服务启动失败

The project is as follows:

Initializing a configuration replica set to create a replication set

We first configure a replication set containing three nodes, and one more node will be added to the next node.

mongochen={"_id":"chenrs","members":[{"_id":0,"host":"172.16.10.27:27017"},{"_id":1,"host":"172.16.10.27:27018"},{"_id":2,"host":"172.16.10.27:27019"}]}

Initializing a replication set

When initializing a replica set, ensure that there is no data from the node, or it will cause data loss from the node server after initialization.

rs.initiate(chen)

To view the status of each node in a replication set

chenrs:SECONDARY> rs.status(){    "set" : "chenrs",    "date" : ISODate("2018-07-14T14:40:20.756Z"),         ···     //省略部分内容    "members" : [        {            "_id" : 0,            "name" : "172.16.10.27:27017",            "health" : 1,             //健康值为1，代表该节点处于运行良好状态            "state" : 1,               //1代表主            "stateStr" : "PRIMARY",   //处于peimary状态         ···     //省略部分内容        },        {            "_id" : 1,            "name" : "172.16.10.27:27018",            "health" : 1,            "state" : 2,              //2代表从            "stateStr" : "SECONDARY", //处于secondary状态        ···     //省略部分内容        },        {            "_id" : 2,            "name" : "172.16.10.27:27019",            "health" : 1,            "state" : 2,            "stateStr" : "SECONDARY",        ···     //省略部分内容        }}chenrs:PRIMARY>            //此时节点状态已经发生转变

Node management (done on primary) adding nodes

rs.add("172.16.10.27:27020")

Delete a node

rs.remove("172.16.10.27:27020")

Fail-over switchover simulates primary node corruption

ps aux | grep  mongod     //查询本地的节点的进程号kill -9 40882             //杀死主节点进程

View node Status

chenrs:SECONDARY> rs.status(){    "set" : "chenrs",    "date" : ISODate("2018-07-14T15:21:21.426Z"),    "myState" : 2,    "term" : NumberLong(2),    "syncingTo" : "172.16.10.27:27019",    "syncSourceHost" : "172.16.10.27:27019",    "syncSourceId" : 2,           ···   //省略部分内容    "members" : [        {            "_id" : 0,            "name" : "172.16.10.27:27017",            "health" : 0,             //健康值为0，处于停机状态            "state" : 8,            "stateStr" : "(not reachable/healthy)",           ···   //省略部分内容        },        {            "_id" : 1,            "name" : "172.16.10.27:27018",            "health" : 1,            "state" : 2,            "stateStr" : "SECONDARY",            ···   //省略部分内容        },        {            "_id" : 2,            "name" : "172.16.10.27:27019",            "health" : 1,            "state" : 1,            "stateStr" : "PRIMARY",            ···    //省略部分内容        }}

Active switching of master-slave status (done on primary)

rs.freeze(30)      //暂停30s不参与选举rs.stepDown(60,30)   //交出主节点位置，维持从节点状态不少于60秒，等待30秒使主节点和从节点日志同步

About the electoral principles of replication sets I will write in the next blog, please look forward to!!

Configuring a MongoDB Replication set