MongoDB replica set implementation and read/write splitting

MongoDB replica set implementation and read/write splitting

In the previous article "building an instance in MongoDB master-slave mode", we briefly introduced how to build a master-slave Mongodb server environment. However, Mongodb does not officially recommend the master-slave structure because the master-slave mode has the following two disadvantages:

(1) When the master node is unavailable, it cannot be automatically switched to the slave node, and business access cannot be guaranteed;

(2) All read/write operations are performed on the master node, resulting in high access pressure on the master node;

Therefore, Mongodb provides us with another recommended method, that is, using replica set ReplicaSets. This article briefly describes how the replica set is implemented and how to solve the above two problems.

First, we will build a replica set (because there are not so many server machines, here we use a single machine, using different port numbers to simulate Mongodb instances on different machines ).

Step 1: We Start three different Mongodb instances on ports 1111, 2222, and 3333 of the local machine;

Mongod -- port 1111 -- dbpath F:/mongodb1/data/db -- logpath F:/mongodb1/data/log/mongodb. log -- replSet test -- logappend
Mongod -- port 2222 -- dbpath F:/mongodb2/data/db -- logpath F:/mongodb2/data/log/mongodb. log -- replSet test -- logappend
Mongod -- port 3333 -- dbpath F:/mongodb3/data/db -- logpath F:/mongodb3/data/log/mongodb. log -- replSet test -- logappend

Here we have started three Mongodb instances and specified the corresponding data directory and log directory, here we need to use -- replSet to indicate that the Mongodb instance is a node in the replica set, and the replica set name is test.

Step 2: log on to an instance, write commands, and combine three different Mongodb instances to form a complete replica set;

Config_test = {"_ id": "test", members :[
{_ Id: 0, host: "127.0.0.1: 1111 "},
{_ Id: 1, host: "127.0.0.1: 2222 "},
{_ Id: 2, host: "127.0.0.1: 3333 "},
]};
Here, members can contain multiple values. Here, we list the three Mongodb instances that have just been started and use the _ id field to name the replica set test.

Step 3: run the following command to initialize the replica set.

Rs. initiate (config_test );

The above configuration is used to initialize the Mongodb replica set.

In the preceding three steps, you can create a replica set named test consisting of three Mongodb instances. To view the status of the replica set, run the rs. status () command.

Now that the replica set is set up, can this replica set solve the two problems in the master-slave mode above?

First, let's look at the first problem. We will shut down the Mongodb server with port 1111, and then we will use the rs. status () command to check it, as shown below:

Here, you need to briefly describe individual fields in the returned information. health indicates whether the node in the replica set is normal, 0 indicates abnormal, 1 indicates normal, and state indicates the node identity, 0 indicates that the node is not the master node, 1 indicates the master node, stateStr is used to describe the node identity characters, PRIMARY indicates the master node, SECONDARY indicates the slave node, and name indicates the ip address and port information of the replica set node, and so on.

From the returned packet information, we can see that after Port 1111 is disabled, the node is inaccessible in the status of the replica set node, reselect the generated primary node is the Mongodb instance started on port 3333. As for the selection process, we will talk about it in the following article. Here we will briefly talk about it. After the master node fails, other nodes can initiate an election. As long as a node receives more than half of the votes of the replica set Node during the election process and does not vote against the node, the node can become the master node.

After the Mongodb instance on port 1111 fails, port 3333 becomes the new master node and can be automatically switched. Therefore, the first problem is solved.

The second problem is that the master node is responsible for all the read and write operations, resulting in heavy pressure on the master node. How can this problem be solved in the replica set? Normally, we access the replica set in Java as follows:

Public class TestMongoDBReplSet {
Public static void main (String [] args ){
Try {
List <ServerAddress> addresses = new ArrayList <ServerAddress> ();
ServerAddress address1 = new ServerAddress ("127.0.0.1", 1111 );
ServerAddress address2 = new ServerAddress ("127.0.0.1", 2222 );
ServerAddress address3 = new ServerAddress ("127.0.0.1", 3333 );
Addresses. add (address1 );
Addresses. add (address2 );
Addresses. add (address3 );
MongoClient client = new MongoClient (addresses );
DB db = client. getDB ("test ");
DBCollection coll = db. getCollection ("test ");
// Insert
BasicDBObject object = new BasicDBObject ();
Object. append ("key1", "value1 ");
Coll. insert (object );
DBCursor dbCursor = coll. find ();
While (dbCursor. hasNext ()){
DBObject dbObject = dbCursor. next ();
System. out. println (dbObject. toString ());
}
} Catch (Exception e ){
E. printStackTrace ();
}
}
}

However, the Read and Write pressure in the replica set cannot be dispersed. In fact, at the code level, we can set to only read data from the secondary node when accessing the replica set again. The read/write splitting structure of the replica set is shown in:

To implement read/write splitting on the replica set, we need to implement the following two steps:

(1) set setSlaveOk on the replica node;

(2) At the code level, set to read data from the copy Node during the reading operation, as shown below:

Public class TestMongoDBReplSet {
Public static void main (String [] args ){
Try {
List <ServerAddress> addresses = new ArrayList <ServerAddress> ();
ServerAddress address1 = new ServerAddress ("127.0.0.1", 1111 );
ServerAddress address2 = new ServerAddress ("127.0.0.1", 2222 );
ServerAddress address3 = new ServerAddress ("127.0.0.1", 3333 );
Addresses. add (address1 );
Addresses. add (address2 );
Addresses. add (address3 );
MongoClient client = new MongoClient (addresses );
DB db = client. getDB ("test ");
DBCollection coll = db. getCollection ("test ");

BasicDBObject object = new BasicDBObject ();
Object. append ("key1", "value1 ");
ReadPreference preference = ReadPreference. secondary ();
DBObject dbObject = coll. findOne (object, null, preference );
System. out. println (dbObject );
} Catch (Exception e ){
E. printStackTrace ();
}
}
}

In addition to secondary, the read parameters can also be used. Their meanings are as follows:

Primary: the default parameter. It reads data only from the master node;
PrimaryPreferred: most of the data is read from the master node. Data is read from the secondary node only when the master node is unavailable.
Secondary: reads data only from the secondary node. The problem is that the data on the secondary node is "old" than that on the primary node ".
SecondaryPreferred: reads data from secondary nodes first. When a secondary node is unavailable, it reads data from the master node;
Nearest: whether it is a master node or a secondary node, it reads data from the node with the lowest network latency.

In this way, the read/write splitting on the replica set is realized, and the second problem mentioned above is solved. In another important aspect of replica sets, how does one synchronize Master/Slave Data? How to elect a new master node? How do I synchronize the information of each node in the replica set? These questions will be described in another article. If you are interested, please pay attention to them. Thank you. Pai_^

For more MongoDB tutorials, see the following:

CentOS compilation and installation of php extensions for MongoDB and mongoDB

CentOS 6 install MongoDB and server configuration using yum

Install MongoDB2.4.3 in Ubuntu 13.04

MongoDB beginners must read (both concepts and practices)

MongoDB Installation Guide for Ubunu 14.04

MongoDB authoritative Guide (The Definitive Guide) in English [PDF]

Nagios monitoring MongoDB sharded cluster service practice

Build MongoDB Service Based on CentOS 6.5 Operating System

MongoDB details: click here
MongoDB: click here

This article permanently updates the link address: