MongoDB Copy Set build tutorial (Personal action Note)

Many companies are using MongoDB, has no time to study, recently a good whole, take notes, directly on the operation steps, about MongoDB theory knowledge can search other information, can also contact me to obtain

MongoDB official has not recommended the use of master-slave mode , the alternative is the use of replica set mode, master-slave mode is actually a single copy of the application, there is no good scalability and fault tolerance. The replica set has multiple replicas to ensure fault tolerance, even if a copy hangs up there are many replicas exist, and resolves the first problem above "The primary node is dead, the entire cluster will automatically switch". No wonder MongoDB officially recommends using this model. Let's take a look at the schema diagram of the MongoDB replica set:

The diagram lets you see that the client is connected to the entire replica set, and does not care about which machine is hanging off. The primary server is responsible for reading and writing the entire replica set, the replica set synchronizes the data backup periodically, but when the primary node hangs, the replica node elects a new primary server, all of which do not need to be concerned about the application server. Let's take a look at the schema after the main server is hung off:

When the replica node in the replica set is detected by the heartbeat mechanism after the primary node is hung off, the primary node's election mechanism is initiated in the cluster, and a new primary server is automatically elected. Looks very cow x appearance, we hurriedly operation deployment!
The number of officially recommended replica set machines is at least 3, so we also configure the tests according to this number.

1, prepare two machines 192.168.176.129, 192.168.176.130, 192.168.176.131. 192.168.176.129 as the replica set master node , 192.168.176.130, 192.168.176.131 as replica set replica nodes .

2. Set up MongoDB copy set Test folder and data directory on each machine respectively

　　

3. Start the MongoDB service of three machines separately:

#cd/opt/soft/mongodb/mongodb-linux-x86_64-3.2. 1/bin# Specify the data file path and replica set name at startup - -dbpath/opt/soft/mongodb/data/--replset repset 

4. Initialize the replica set log in any one of the three machines, for example: 129 this one

#/opt/soft/mongodb/mongodb-linux-x86_64-3.2.1/bin  /mongo
........ Log information omitted
#>>config = {_id:"Repset", members:[{_id:0, Host:"192.168.176.129:27017"}, {_id:1, Host:"192.168.176.130:27017"}, {_id:2, Host:"192.168.176.131:27017"}] }

Printing information:

    {              "_id":"Repset",              " Members" : [                      {                              "_id":0,                              "Host":"192.168.176.129:27017"                      },                      {                              "_id":1,                              "Host":"192.168.176.130:27017"                      },                      {                              "_id":2,                              "Host":"192.168.176.131:27017"                      }              ]      }  

# Initialize replica set configuration rs.initiate (config);

#如果成功了返回
{"OK": 1}

# If a message appears, look at the server's firewall
{
"OK": 0,
"ErrMsg": "Replsetinitiate quorum check failed because not all proposed set members responded affirmatively:192.168.176. 129:27017 failed with no route to host, 192.168.176.131:27017 failed with no route to host ",
"Code": 74
}

5. View cluster status

　　

This entire replica set has been built. Let's test it now.

The master node is responsible for the write operation, so we write on the 130 machine

Repset:primary> Db.benxq.insert ({"name":"zhangsan"})

Perform read operations on 131 machines read

Repset:secondary> Db.benxq.find ()
Error " OK " 0 " errmsg " " Not Master and Slaveok=false " " Code " 13435 }

Repset:secondary> Db.benxq.find ();

6. Fail-over Test

We will stop 130 of this primary node to mimic server failure and execute Rs.status () on 129.

　　

We can see that the 131 of this server has been elected for the new master node, this is our reboot 130, will automatically become the secondary node.

　　

MongoDB Copy Set build tutorial (Personal action Note)