MongoDB Distributed cluster (2, replica set)

Overview

replica set is a master-slave replication, is a self-failover function of the master-slave replication, to solve the shortcomings of the master-slave replication, the realization of the main server failure, no human intervention, the system automatically from the new election of the main server function.

deployment Diagram

The picture is copy others, interested can view the person's blog, write very good

Replica Set Configuration

<strong>   </strong>//Start server (log on to each server)    mongod--dbpath d:/data/--replset repset    //Initialize replica set ( Login to any server)    config = {_id: "Repset", members:[                          //_id value = = Replset parameter        {_id:0, Host: "192.168.1.136:27017"},        {_id:1, Host: "192.168.1.137:27017", priority:10},        {_id:2, Host: "192.168.1.138:27017", priority:20},        //Quorum node: For voting only, to prevent the primary node from being selected, quorum and non-quorum (only in initialization settings)        {_id:3, Host: " 192.168.1.139:27017 ", arbiteronly:true}]        }    rs.initiate (config);

       The configuration of the replica set is also very simple, such as the above configuration can be implemented, in the replica set involves a lot of different types of nodes, you can see the corresponding comments, there are unclear can be looked at, here are some other aspects of the replica set operations, you can try

Node Operation    Rs.status ();                        View cluster node status (login to any server)    Rs.add ("192.168.1.140:27017");      Add replica node    rs.remove ("192.168.1.140:27017");   Delete Node Node properties operation (login Master node server)    cfg=rs.conf ();    Hidden node: Can vote, can back up data, not be used by the client (not the main node)    cfg.members[1].priority=0;    Cfg.members[1].hidden=1;    Deferred replication node: for backup, delay synchronizing data from master node, avoid user error    cfg.members[2].priority=0;    cfg.members[2].slavedelay=3600;    Permanent Replica node: Prevent the node with low performance becomes the main node    cfg.members[3].priority=0;    Pure Backup Replica node: no voting    cfg.members[4].votes=0;    Rs.reconfig (CFG); read/write Detach    //Set replica node readable (replica node server)    Db.getmongo (). Setslaveok ();

       After configuring the replica set, we are unable to read the contents of the replica node server, we need to set up the following to achieve the read and write separation, of course, the primary and secondary server does not need this setting to achieve master-slave replication

    Read/write Detach    //Set replica node readable (replica node server)    Db.getmongo (). Setslaveok ();<strong></strong>

Java Client OperationsTo achieve the read and write separation of the replica set, we need to set the appropriate settings on the Java client, the following is the Java Client Core code, of course, first of all, we need to do is to download the corresponding MongoDB Java driver

<span style= "FONT-SIZE:18PX;" >    //Distributed cluster (configure multiple servers, as long as one can run on the line)    list<serveraddress> serveraddresslist = new arraylist< Serveraddress> ();    Serveraddresslist.add (New ServerAddress ("192.168.24.1", 10000));    Serveraddresslist.add (New ServerAddress ("192.168.24.2", 10000));    Mongoclient mongoclient = new Mongoclient (serveraddresslist);</span>

<span style= "FONT-SIZE:18PX;" >    //Set read/write separation    readpreference readpreference = readpreference.secondarypreferred ();    Database.setreadpreference (readpreference);    Primary: Default parameter, read only from primary node    primarypreferred: Most of the data is read from the primary node and only read    from the secondary node when the primary node is not available Secondary: Only read from the secondary node, the problem is that the data of the secondary node is "old"    than the primary node data Secondarypreferred: read from the secondary node is preferred, and the secondary node is not available to read data from the primary node    nearest: Either the primary node, the secondary node, and the data is read from the node with the lowest network latency. </span>

The above code is not the complete code, is some of the core code, if you want to implement this, you can start from a single server read and write operations, the following gives a simple Java Client Implementation example, we are interested can be downloaded to look at. Instance code. This instance code implements the operation of a fixed set of MongoDB and a file.

the pros and cons of replica sets Advantages

read/write Separation: Master node data read and write, default replica node cannot read and write directly (can be set read-only)

Data backup: The replica node reads the master node's Oplog (Operation Log), executes

Failover: Primary node is down and the master node is automatically re-elected (the higher the priority 0-100, the greater the opportunity)

Disadvantages

cluster only , no distributed

Description

number of replica set nodes

Preferably odd: Avoid electing the master node

Up to 12: High Cost of replication

Up to 7 participating elections: Increase election time

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

MongoDB Distributed cluster (2, replica set)