Overview
replica set is a master-slave replication, and is a master-slave replication with self-failover capability. Overcome the shortcomings of the above-mentioned master-slave replication. After you implement a host server problem. No human intervention is required. The system itself proactively elects a new primary server function.
deployment Diagram
The map is copy others, interested to be able to view the person's blog, written very good
Replica Set Configuration
<strong> </strong>//Start server (login per server) Mongod--dbpath d:/data/--replset repset // Initialize replica set (login arbitrary 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. Prevents 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, as the above configuration can be implemented. Very many different types of nodes are involved in the replica set. We can see the corresponding gaze. There is no way to check again. Here are some other things about the replica set. You can try
Node Operation Rs.status (); View cluster node status (login at random server) rs.add ("192.168.1.140:27017"); Join the replica node rs.remove ("192.168.1.140:27017"); Delete Node Node properties operation (login Master node server) cfg=rs.conf (); Hidden nodes: Can vote, can back up data, not be used by the client (not as 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 we have configured the replica set, we are unable to read the contents of the replica node server, which requires us to do the following settings, for example. Ability to achieve read and write separation, of course, the master-slave 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>
javaclient OperationTo achieve the read and write separation of the replica set, we need to make the corresponding settings on the Java client. The following is the core code of Javaclient, of course. First of all, what we need to do is download the corresponding MongoDB Java driver
<span style= "FONT-SIZE:18PX;" > //Distributed clusters (configure multiple servers.) Only one executable is required) 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 number of parameters. Read only from the primary node primarypreferred: Most of the data is read from the primary node, and only the primary node is unavailable to read from the secondary node secondary: read from the secondary node only , the problem is that the data of the secondary node is "old" secondarypreferred than the primary node data : The read operation takes precedence from the secondary node. The secondary node reads data from the primary node when it is not available 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, assuming that you want to implement this, can start from a single server read and write operations. Here is an example of a simple javaclient implementation of the server, and we are interested to be able to download it and look at it. Instance code. This instance code implements the operation of a fixed set of MongoDB and a file.
the pros and cons of replica sets
Strengths
read/write Separation: Master node data read and write, default replica node cannot read and write directly (can be set to read only)
Data backup: The replica node reads the master node's Oplog (Operation Log), runs
failover: The primary node is down. The system will voluntarily re-elect the master node (the greater the priority 0-100, the greater the opportunity)
Disadvantages
There are only clusters, 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 participation elections: Add election time
MongoDB Distributed cluster (2, replica set)