Window configuration mongodb cluster (replica set)

Parameter explanation:

dbpath: data storage directory

logpath: log storage path

pidfilepath: process file, useful for shutting down services

logappend: log in append mode (boolean value)

replSet: The name of the replica set, each replica set has the same name

port: port number of mongodb

oplogSize: The maximum size of the mongodb operation log file, the unit is Mb, the default is 5% of the remaining space on the hard disk

noprealloc: do not preallocate storage

fork: run the process in the background (used by linux)

directoryperdb: create a folder for each database according to the database name to store

health indicates whether the node in the replica set is normal, 0 means abnormal, 1 means normal

state represents the identity of the node, 0 represents a non-primary node, and 1 represents a primary node

stateStr is used to characterize the node identity, PRIMARY represents the primary node, SECONDARY represents the secondary node

name is the ip and port information of the replica set node

priority: the priority of the replica set node, the range of this value is 0--100, the larger the value, the higher the priority, the default value is 1, if the value is 0, then it cannot become primary

arbiterOnly: set the arbiter node

First, let's build a replica set (the replica set structure is 1 master node, one slave node and one arbitration node)

Step 1: We start three different Mongodb instances on the three ports 1001, 1002 and 1003 of the local machine;

mongod --port 1001 --dbpath F:/mongos/mongodb1/data  --logpath  F:/mongos/mongodb1/log/mongodb.log  --pidfilepath F:/mongos/mongodb1/mongodb1.pid  --replSet test --logappend  --directoryperdb
mongod --port 1002 --dbpath F:/mongos/mongodb2/data --logpath F:/mongos/mongodb2/log/mongodb.log  --pidfilepath F:/mongos/mongodb2/mongodb2.pid --replSet test --logappend   --directoryperdb
mongod --port 1003 --dbpath F:/mongos/mongodb3/data --logpath F:/mongos/mongodb3/log/mongodb.log  --pidfilepath F:/mongos/mongodb3/mongodb3.pid --replSet test --logappend   --directoryperdb

Step 2: Log in to the 1001 instance and write instructions to combine three different Mongodb instances to form a complete replica set;

cd F:\mongos\mongodb1\bin

mongo 127.0.0.1:1001

use admin

config_test={_id:"test",members:[
    {_id:0,host:"127.0.0.1:1001",priority: 1 },
    {_id:1,host:"127.0.0.1:1002",priority: 1 },
    {_id:2,host:"127.0.0.1:1003",arbiterOnly: true },
]};
Here, members can contain multiple values, here are the three Mongodb instances just started, and through _ The id field gives the replica set the name test.

Step 3: Initialize the replica set by executing the following command.

rs.initiate(config_test);

Here the Mongodb replica set is initialized using the above configuration.

rs.status()

Want to see the status of a replica set

At this point, a replica set named test consisting of three Mongodb instances has been built.

The replica set is now set up, so can this replica set solve the two problems of our master-slave mode above?

Let's start with the first question. We shut down the Mongodb server on port 1001, and then we use the rs.status() command to check it, as shown below:

From the returned packet information, it can be seen that after port 1001 is closed, the node is unreachable in the state of the replica set node. The master node generated by re-election is the Mongodb instance started on port 1002. The election process is as follows. After the node hangs, other nodes can initiate election behavior. As long as a node gets more than half of the votes of the replica set nodes during the election process and no node votes against it, the node can become the master node. (Please refer to the starting position for parameter comments) After the Mongodb instance on port 1001 hangs up, 1002 becomes the new master node, which can realize automatic failover.

As for the second question, that is, the master node is responsible for all read and write operations, which causes a lot of pressure on the master node, so how to solve this problem in the replica set? Normally, we access replica sets in Java like this:

public class TestMongoDBReplSet {   
    public static void main(String[] args)  {  
        try {   
            List<ServerAddress> addresses = new ArrayList<ServerAddress>();    
            ServerAddress address1 = new ServerAddress("127.0.0.1",1001);   
            ServerAddress address2 = new ServerAddress("127.0.0.1",1002);   
            ServerAddress address3 = new ServerAddress("127.0.0.1",1003);   
            addresses.add(address1);    
            addresses.add(address2);   
            addresses.add(address3);   
            MongoClient client = new MongoClient(addresses);   
            DB db = client.getDB( "testdb");   
            DBCollection coll = db.getCollection( "testdb");   
            // 插入   
            BasicDBObject object = new BasicDBObject();    
            object.append("userid","001");   
            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 above cannot achieve distributed read and write pressure in the replica set. 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 separation structure of the replica set is shown in the following figure:

In order to achieve read-write separation on a replica set, we need to implement the following two steps:

(1) Set setSlaveOk on the replica node;

(2) At the code level, set the read data from the replica node during the read 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",1001);   
            ServerAddress address2 = new ServerAddress("127.0.0.1",1002);   
            ServerAddress address3 = new ServerAddress("127.0.0.1",1003);   
            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("userid","001");   
            ReadPreference preference = ReadPreference.secondary();    
            DBObject dbObject = coll.findOne(object, null , preference);    
            System. out .println(dbObject);    
        } catch (Exception e) {   
            e.printStackTrace ();    
        }   
    }   
}

In addition to secondary, there are several other parameters that can be used for read parameters, and their meanings are as follows:

primary: the default parameter, only reads from the primary node; 
primaryPreferred: mostly reads data from the primary node, only reads data from the secondary node when the primary node is unavailable. 
Secondary: Only read operations are performed from the secondary node. The problem is that the data of the secondary node will be "older" than the data of the primary node. 
secondaryPreferred: Read operations from the secondary node are prioritized, and data is read from the primary node when the secondary node is unavailable; 
nearest: Whether it is the primary node or the secondary node, data is read from the node with the lowest network latency.