MongoDB Master-slave replication + cluster

　　I. The concept of read and write separation

　　　　Read and write separation, the basic principle is to let the main database processing transaction increment, change, delete operation (INSERT, UPDATE, delete), and from the database processing select query operation. Database replication is used to synchronize changes caused by transactional operations to the slave database in the cluster.

The purpose of Read and write separation is to realize the request shunt in high concurrency scenario, avoid the centralization of database access, and result in performance degradation or even downtime.

Second, the master-slave Replication Introduction

　　　　In the MongoDB cluster, there will be a master node that is designated as Master, which is used by the client for adding and deleting data. At the same time, there will be a node in the cluster that is designated as slave, that is, from the node, the node mainly receives the read from the client, the retrieval operation, does not have the function of adding and removing and changing operation.

After the Master node processing add and delete operations, will synchronize the data in real-time to its bound from the node, the master-slave replication to have at least two DB instances, and each from the node needs to know the address of the master node, if it is in Linux remember to open the master-slave firewall.

The advantages of master-slave replication are more flexible, suitable for data backup, manual data recovery after failure, and expansion of reading data.

　　　　

Third, master-slave replication Limitations

　　　　(1) MongoDB currently recommends using a replica set for cluster management, it is not recommended to use a simple master-slave copy, the copy set in this MONGODB series blog is described.

(2) master-slave replication after the master outage, there is no automatic election master mechanism, leading to the main node service, you can not provide external additions and deletions to the operation.

(3) All additions and deletions are operated on the master node, which may result in degraded performance of the primary node.

(4) The data from the node to the master node is a full-volume copy, and the pressure on the slave node is not small.

Iv. simple configuration and implementation of master-slave replication

　　　　The device is limited for easy implementation and can be used to simulate the master and slave nodes on a single machine. Create the master directory in the C drive, create the slave directory on the e disk, the master directory as the primary node data directory, and the slave directory as the directory from which the node data resides.

Note: The master node and the slave node want to specify a different port.
Start Master node: Mongod--dbpath C:\master--port 666--master
Start from node: Mongod--dbpath E:\slave--port 888--slave--source localhost:666

After a successful start, the master node can be connected to the operation, and the operation of the master node will be synchronized to the slave node, while the insertion from the node will be reported to not master prompt and refused to write data.

　　　　Configuration Implementation Explanation

Master: The default is False, to set the current node as the primary node, you need to start adding--master on the server
Slave: The default is False, to set the current node as the slave node, you need to start adding--slave on the server
Source: Default is null, used from node, specifies the source of replication from the node, that is, the address of the primary node, in the format:Only: Default is NULL, used to replicate all databases on the default replication master node from the node, by setting this key to specify the name of the database to replicate
Slavedelay: Sets the delay time for the master node to be synchronized from the node, set from node, default to 0, in seconds.
Autoresync: The default is False, which is used to set from node. Whether to automatically resynchronize. Set to true to force automatic resynchronization from the node if the master node falls behind for more than 10 seconds. If the oplogsize is too small, there may be a problem with this setting. If the Oplog size is not large enough to store the difference between the change state of the primary node and the state of the node, forcing resynchronization in this case is not necessary. When the Set Autoresync option is set to false,10 minutes from the node, no automatic resynchronization is made greater than 1 times.

　　　　What is Oplog?

　　　　The operation of the master node is logged as Oplog, stored in the system database local collection Oplog. $main, each document in this collection represents an operation (excluding queries) from the primary node, which periodically fetches oplog data from the primary server and executes it natively. Oplog uses a fixed set, and as the operation gradually increases, the new document will gradually overwrite the old document.

　　　　

MongoDB Master-slave replication + cluster