Replica set of MongoDB in Linux

I. node types

Standard: a regular node that stores a complete copy of data and participates in voting. It may become an active node.

Passive: stores complete data copies and participates in voting. It cannot be an active node.

Arbiter: An arbitration node that only participates in voting and does not receive copied data. It cannot become an active node.

Ii. parameter description
-- Dbpath: Data File Path
-- Logpath: Log File Path
-- Port port number. The default value is 27017. This port number is also used here.
-- Replset: the name of the replica set. The parameter of each node in a replica set must use a replica set name. Here is test.
-- Replset is followed by the IP address and port of other standard nodes.
-- Maxconns maximum number of connections
-- Fork background running
-- The logappend log file is used cyclically. If the log file is full, the new log will overwrite the latest log.

Note:
1. If you do not need to copy the complete data like MySQL, the slave database will brake to copy the complete data of the master database.
2. The cluster database is automatically configured as read-only.
3. MongoDB is started for a long time for the first time. Please wait.
4. Most management commands must be executed in the admin database by using admin.

3. Create a replica set
Environment Description:

IP: 10.0.0.2 master
IP: 10.0.0.3 slave
IP: 10.0.0.4 slave
IP: 10.0.0.5 arbiter

1. Create a data directory: mkdir server1 server2 server3 server4

2. Enable MongoDB:

First, Let's name the replica set fuben.

Enable for 10.0.0.2:/usr/local/MongoDB/bin/mongod -- dbpath =/usr/local/MongoDB/server1 -- logpath =/usr/local/MongoDB/dblog1 -- replset fuben: 10.0.0.3 -- fork

(Note: -- fork is the creation daemon. -- logpath and -- fork must coexist)

Enable for 10.0.0.3:/usr/local/MongoDB/bin/mongod -- dbpath =/usr/local/MongoDB/server2 -- logpath =/usr/local/MongoDB/dblog2
-- Replset fuben: 10.0.0.2 -- fork

After the service is started, we can observe the MongoDB startup information through the log file, and one of the highlights of the replica set is the automatic detection function: after the specified server, mongoDB automatically searches for and connects to other nodes.

3. initialize nodes

We connect to one of the nodes and use the replsetinitiate command for initialization. This command requires a configuration object that specifies the name of each set member.

DB. runcommand ({"replsetinitiate ":{

'_ Id': 'fuben ',

'Members ':[

{
"_ Id": 0,
"Host": "10.0.0.2"
},
{
"_ Id": 1,
"Host": "10.0.0.3"
}

]

}

})

Or:

>>config = {_id:"test",members:[... {_id:0,host:'10.0.0.2'},... {_id:1,host:'10.0.0.3'},]... }>rs.initiate(config);{   "info" : "Config now saved locally.  Should come online in about a minute.",   "ok" : 1}

During this period, one of the nodes will be elected as the master node.

In this way, we create a replica set. When we write data into the master database, the data will be synchronized, but the data in the master database cannot be viewed from the server, we can change the slave server to readable by setting

The log shows that the slave server reads local. oplog. RS under the master server every 10 seconds for synchronization.

We can view the details in the replica set through: Rs. Status (), or through RS. ismaster () to check whether the server is a master

4. Add slave servers later

Enable 10.0.0.4:/usr/local/MongoDB/bin/mongod -- dbpath =/usr/local/MongoDB/server3 -- logpath =/usr/local/MongoDB/dblog3 -- replset
Fuben: 10.0.0.2 -- fork

First, we have enabled MongoDB for the 10.0.0.4 server.

We add Rs. Add ("10.0.0.4: 27017") on the master server to add the server to the replica set.

5. Add arbitration nodes

Enable 10.0.0.5:/usr/local/MongoDB/bin/mongod -- dbpath =/usr/local/MongoDB/server4 -- logpath =/usr/local/MongoDB/dblog4 -- replset
Fuben: 10.0.0.2 -- fork

First, we have enabled MongoDB (arbiter) of the 10.0.0.5 server)

We add Rs. addarb ("10.0.0.4: 27017") to the master server so that the server is added to the arbitration node of the replica set.

This node does not participate in data replication, but only participates in voting to select the master node.

6. Synchronization Mechanism of MongoDB replica sets

The purpose of data replication is to maximize data availability and prevent the whole site from being inaccessible due to spof. MongoDB replica sets can be written by only one server at a time, the master-slave replication of the replica set is also an asynchronous synchronization process. The slave side obtains logs from the primary side, then perform the operations recorded in the log in full order on the user (this log does not record the query operations). This log is the oplog in the local database. RS table, which is relatively large on 64-bit machines by default, accounting for 5% of the disk size, oplog. the RS size can be set in the startup parameter -- oplogsize 1000, in MB. We recommend that you set this value to a greater value in the production environment to prevent synchronization failures.

7. View synchronization status

We use dB. printslavereplicationinfo () to view the information. Here, we show the synchronization time and other information.

For example:

Source: 127.0.0.1: 10000
Syncedto: Tue Jul 16 2013 15:18:52 GMT + 0800 (CST)
= 5337 secs ago (1.48hrs)
Source: 127.0.0.1: 10003
Syncedto: Tue Jul 16 2013 16:05:22 GMT + 0800 (CST)
= 2547 secs ago (0.71hrs)
Source: 127.0.0.1: 10002
No replication info, yet. State: arbiter

Source: slave database IP address and port

Syncedto: Current synchronization status and the last synchronization time

It can be seen from the above that when the database content remains unchanged, it is not synchronized, and the database changes will be synchronized immediately.

DB. printreplicationinfo () view the oplog size and time range of operations in oplog

For example, configured oplog size: 50 MB
Log length start to end: 9071 secs (2.52hrs)
Oplog first event time: Tue Jul 16 2013 14:20:40 GMT + 0800 (CST)
Oplog last event time: Tue Jul 16 2013 16:51:51 GMT + 0800 (CST)
Now: Tue Jul 16 2013 17:10:35 GMT + 0800 (CST)

It is illustrated that the oplog is configured as 50 m, and the time length of the log record and so on.

8. delete a node

For various reasons, I want to delete a node and leave the server idle.

Then run the Rs. Remove ("IP + port") command to remove the node.

Example: Rs. Remove ('10. 0.0.3: 27017 ')

Output result:

Tue Jul 16 16:51:52. 180 dbclientcursor: init call () failed
Tue Jul 16 16:51:52. 210 JavaScript Execution failed: Error doing query: failed at src/Mongo/Shell/query. JS: L78
Tue Jul 16 16:51:52. 229 trying reconnect to 127.0.0.1: 10001
Tue Jul 16 16:51:52. 231 reconnect 127.0.0.1: 10001 OK

In this way, we can use Rs. Status to check that this node is no longer available.

9. Synchronize files

The Operation Records of the master node are stored in the oplog (operation logs). The oplog is stored in a special database called local, and the oplog is stored in oplog. Rs.

You can view the operation log through dB. oplog. Rs. Find ().

Each document in oplog records an operation on the master node: Key in the document:

TS: The operation timestamp. It consists of a four-byte Timestamp and a four-byte counter.

OP: operation type, only one byte of Code (for example, u -- Update, I-insert n -- null)

NS: The namespace used to perform the operation, that is, the set name.

O: Specifies the document to be executed, that is, the data to be inserted, the updated data, and so on.

10. Slave node synchronization

When the slave node is started for the first time, the data on the master node will be completely synchronized, which takes a lot of time. If the operations on the slave node have been dropped too far by the master node, the slave node will not be able to keep up, because the data on the master node is too new, it may be because the slave node fails or goes down, or the slave node shares the master node as the read server. In this way, resources are consumed and read-only resources cannot be synchronized, in this way, the data from the node will be no longer available.

You can run the: {'resync': 1} command to manually re-Synchronize, or add the parameter -- autoresync when starting the slave node to re-synchronize. Re-synchronization is costly and should be avoided as much as possible by configuring a large enough oplog