node. js MongoDB Replset

With the rise of web2.0, the application of high-concurrency large data volume is becoming more and more obvious, and the traditional relational database seems to be weak in this aspect. A spear has its own shield, and the presence of a memory db compensates for the shortcomings of the traditional relational db. The most popular memory db in the market now is Redis, Memcach, MongoDB. The preceding two are stored in key-value form, and MongoDB is based on some of the characteristics of relational database tables and supports indexing.

MongoDB is a good choice for scenarios where there is a requirement for large data volumes and data correlation.

Replica set is a copy cluster scheme for MongoDB, which is superior to the traditional master-slave method of database.

Traditional master-slave approach. Master is responsible for reading and writing, Slaver is responsible for synchronizing data from master, once master is down. Slaver is wasted, and such a way is flawed in terms of disaster preparedness. The clustering mechanism of MongoDB's replica set overcomes this flaw.

Replica Set:

Mainly divided into: primary (master node, provide additions and deletions to change services), Slaver (Standby node. Just provide read), arbiter (quorum node, does not store data, is solely responsible for quorum).

Process: Client reads and writes data from primary node, slaver synchronizes data from primary, when primary down. Arbiter will be in 10 seconds from a number of slaver nodes to choose a healthy slaver replacement primary, thus reducing the disaster . Arbiter The node itself does not store data. Just the execution of primary and slaver in the monitoring cluster (assuming the arbiter outage, the entire cluster is useless, the only disadvantage ).

Slaver simply provides read functionality that cannot be written, our project query needs to be able to connect slaver nodes, which greatly reduces the load on the primary primary node.

Here is the flowchart for Replica Set :

The principle of Replica Set We are clear, you may ask. We are programming, for primary, slaver so many db. We must write the data to the primary node. Suppose the primary node is down and how the program should be tested. How to find a new primary node?

don't worry about it. MongoDB has conquered your doubts. MONGODB provides driver support for a variety of languages. You just need to call the Replica set interface and then follow the instructions to use it, with the following node. JS

var Db = require (' MongoDB '). Db

Server = require (' MongoDB '). Server,
Replset = require (' MongoDB '). Replset;

Cluster Server address
var serveraddr = {
9001: ' 192.168.1.100 ',//Node 1
9002: ' 192.168.1.100 ',//Node 2
9003: ' 192.168.1.100 '//Node 3
}

Collection of cluster Sever objects
var servers = [];
for (var i in serveraddr) {
Servers.push (New Server (Serveraddr[i], parseint (i)));

}

var replstat = new Replset (servers, {});

var db = new db (' blog ', Replstat);

MongoDB operations
Db.open (function (err, db) {
var collection = db.collection (' user ');
Querying a document
Collection.findone ({
Name: ' Jerry '
}, function (err, results) {
Console.info (' query: ', results);
});
Insert a document
Collection.insert ({
Name: ' OK ',
Age:28
}, function (err, results) {
Console.info (' Insert: ' + results);
});

});

The above is configured with several nodes 9001, 9002, 9003, we do not have to pay attention to which is the main node, the standby node, blanking node. The driver will voluntarily infer a healthy master node to give node, we just need to focus on the database operation logic can be.

But there is a problem here. Replica set in the Switch node, there will be a suspended period, we know that node is asynchronous/O, in this suspended period, assuming that node is running a large number of operations, the weak stack memory overflow, reported: Rangeerror:maximum Call stack size Exceeded error. This error is a system-level error. Will cause the app to collapse, even if the catch is abnormal or the DB switch is complete, the program will still hang dead. No solution has been found at the moment. The MONGO-driven API is being researched, attempting to resolve the event by a State listener that reflects the switching process, assuming that the event is triggered, stopping the db operation, and then recovering after the switch is complete, which should solve the problem.

node. js MongoDB Replset