Mongodb source code analysis-Master-slave mode of Replication-Master

Mongodb provides a Replication mechanism that helps us easily implement read/write splitting solutions and supports data security in unexpected situations such as disaster recovery (server power failure.

In earlier versions (1.6), Mongo provides two replication modes: master-slave and replica pair (note: mongodb's latest supported replset replica set method can be regarded as an upgraded version of pair. It solves the restriction that pair can only synchronize between two nodes, supports synchronization of multiple nodes and automatic switch during master-slave downtime, which will be provided after version 1.6 ).

With the former, we can implement read/write splitting (master-slave replication mode), while the latter supports automatic take-over of other slave instances in the cluster when the master server is powered off, and upgrade to the master server. In addition, if an error occurs later, the master status will be changed back to the first server (the server that was down but resumed operation later ).

Mongodb also supports Security Authentication (enable ). Regardless of the replicate method, you only need to create a user name/password for each database in master/slave. The authentication process is as follows:

Slave first searches for a user named "repl" in local. system. users and then uses it to authenticate the master. If the "repl" user is not found, use the first user in local. system. users to authenticate. The local database is the same as the admin database. users in the local database can access the entire db server.

The following describes the two replication configuration methods:

Master-Slave (Master-Slave) mode:
A server can be both master and slave. One slave can have multiple Masters (not recommended, and unexpected results may be generated ).

Configuration Options:
-- The master is started as the master server.
-- Slave is started as a slave server
-- Autoresync: automatically re-sync, because this operation will copy all the documents on the master server, which is time-consuming and will only be performed once in 10 minutes.
-- OplogSize: Specifies the size of the changed data to be stored on the master. If this parameter is not specified, the minimum value is 50 MB on a 32-bit machine and the minimum value is 1 GB on a 64-bit machine, the maximum disk space is 5%.
-- Source master server address (used in combination with -- slave)
-- Only is limited to synchronizing the specified database (the test database is used in the following example)
-- Slavedelay synchronization latency

The following configuration parameters are used locally for testing convenience:
Master: IP-> 10.0.1.103

Mongod -- dbpath = d: mongodbdb -- master -- oplogSize 64
Slave: IP-> 10.0.4.210

Mongod -- dbpath = d: mongodbdb -- slave -- source 10.0.1.103: 27017 -- only test -- slavedelay 100

Supplement: Restricted master-master replication. This mode is safe for insert, query, and delete operations based on _ id. However, concurrent updates to the same object cannot be performed. Mongo does not support full master-master replication. Generally, the master-master mode is not recommended, but in some specific cases, the master-master mode is also available. Master-master only supports final consistency. To configure the master-master, you only need to add the -- master option and -- slave option when running mongod. As follows:
Mongod -- dbpath = d: mongodbdb -- port 27017 -- master -- slave -- source localhost: 27018
Mongod -- dbpath = d: mongodbdb -- port 27018 -- master -- slave -- source localhost: 27017

Replica pairs Mode
After starting in this way, the database automatically negotiates who is the master and who is the slave. Once a database server loses power, the other server automatically takes over and becomes the master from that moment on. In the event of another future error, the master status will be forwarded back to the first server. The command to start mongod in this replication mode is as follows:
Configuration Options:
Mongod -- pairwith <remoteserver> -- arbiter <arbiterserver>
-- Pairwith: remoteserver is another server in pair.
-- Arbiter: arbiterserver is an arbitration Mongo database used to negotiate which of the pair's Masters is used. The arbiter runs on the third machine and uses the "Divide victory" system to determine which machine in the pair cannot be connected to the other machine as the master, generally, the machine that can communicate with arbiter is used as the master node. If the -- arbiter option is not added, both machines act as the master when a network problem occurs.
Note: You can use db. $ cmd. findOne ({ismaster: 1}) to check which database is the master currently.

In this mode, the two machines can only meet the final consistency. When a machine in the replica pair fails completely, it must be replaced by a new one. For example, if n2 in (n1, n2) fails, n3 is used to replace n2. The procedure is as follows:
1. Tell n1 to use n3 to replace n2: db. $ cmd. findOne ({replacepeer: 1 });
2. Restart n1 to make it talk to n3: mongod -- pairwith n3 -- arbiter <arbiterserver>
3. Start n3: mongod -- pairwith n1 -- arbiter <arbiterserver>.
Before n3 data is synchronized to n1, n3 cannot be used as the master. The length of this process is determined by the amount of data.


After learning about the replication mode, we also need to introduce the following question: in this article, mongodb uses the cap collection to store operation logs and then uses logs to copy (synchronize) data between nodes, the operation records saved by the master node are called oplog (operation log ).
 
Oplog exists in a special database called local, In the oplog. $ main set. Each document in Oplog indicates an operation executed on the master node. This document consists of four parts:

Ts: Operation timestamp. The timestamp type is an internal type used to track when an operation is executed. It consists of a 4-byte Timestamp and a 4-byte incremental counter.
Op: the type of the operation to be performed. The size is 1 byte. (For example, "I" indicates insert, "u": update, "d": delete, "n": none, etc)
Ns: namespace (Set Name) for the Operation)
O: the document that executes the operation. For insert, This is the document to be inserted.

In addition, this log only saves the operation that changes the database status. Query operations are not recorded in oplog.

After learning this knowledge, let's take a look at how to debug the source code of the master-slave mode. First, open the mongod project in vs2010 and set the startup parameters as follows:
-- Master -- oplogSize 64 (master IP Address: 10.0.1.103)

For example:

 

Compile the project and start the main service node as follows:

Then we can start a Server Load balancer node locally or on another machine:

Mongod -- dbpath = d: mongodbdb -- slave -- source 10.0.1.103: 27017 -- only test -- slavedelay 100

The following describes the Code Execution Process of the master (master server. First, open the instance. cpp file and find the following method:

// Instance. cpp
// Returns false when request already des end
Void assumeresponse (Message & m, DbResponse & dbresponse, const SockAddr & client ){
......
If (op = dbQuery ){
If (handlePossibleShardedMessage (m, & dbresponse ))
Return;
ReceivedQuery (c, dbresponse, m );
}
// The server (master) receives the message to perform related query operations.
Else if (op = dbGetMore ){
If (! Descriedgetmore (dbresponse, m, currentOp ))
Log = true;
}
.....
}

&