[MongoDB] building a Mongo database replica set (similar to a cluster) on windows platform (3

I have already written the first article about how to build a Mongo database replica set on the windows platform: How to build a Mongo database replica set on the windows platform. Article 2: in this article, we will summarize the replica set and analyze its working principles. I. Common application scenarios and Data

I have already written the first article about how to build a Mongo database replica set on the windows platform: How to build a Mongo database replica set on the windows platform. Article 2: in this article, we will summarize the replica set and analyze its working principles. I. Common application scenarios and Data

I have written two blogs about how to build a Mongo database replica set on windows.

Article 1: How to build a Mongo database replica set on windows

Article 2: Data Synchronization and fault adaptive testing

In this article, we will summarize the replica set and analyze its working principles.

I. Common scenarios

Lost network connection between applications and databases

Scheduled shutdown, power failure, Database Service hard disk failure, etc.

Replication allows failover. Replication allows you to balance read loads between replicas and ensure that the replication nodes are synchronized with the master node.

Ii. Working Principle

Replica sets depend on two basic mechanisms: oplog and heartbeat. oplog make data replication possible, while "heartbeat" monitors the health status and initiates failover;

2.1 about oplog

Oplog is the key to MongoDB replication. oplog is a fixed set located in the local database of each replication node. It records all changes to the database and writes data to the master node each time, it will automatically add a love record to the oplog of the master node, where the blog has enough information to reproduce the data. Once the write operation is copied to a slave node, the oplog of the slave Node also saves a record.

All replica set metadata and oplog are saved in the local database because they cannot be copied;

Then we will look at oplog in detail.

Note that each slave node has its own oplog, And the slave node uses the long polling method to immediately apply new entries from the master node oplog. If the cluster node cannot find the point to be synchronized in the oplog of the master node, the replication will be stopped permanently. This will cause the following exceptions in the log:

Replcation data too stale, halting

Caught syncException

Adjust the oplog size. You can use the db. getReplicationInfo () command to view the allocated oplog space and use the following command to change the default oplog size.

mongod.exe --replSet myapp --oplogSize 1024 

2.2 heartbeat detection and Failover

The heartbeat detection of replica sets helps with election and failover. By default, each replica integrator can ping other members every 2 s. In this way, the system can find out its health status. Run rs. status () to view the health status.

NOTE: If both slave nodes are killed in the three nodes, the log on the master node contains the following statement:

ReplSet can't see a majority of the set,

ReplSet Secondary

This means that if there are no majority of nodes, the master node will downgrade itself to a slave node;

Iii. Management

Because the replica set has many potentially complex configuration items, we will introduce these complex configuration items in detail;

3.1 for configuration details, you can use the rs. initiate () and rs. add () Methods to initialize the replica set. Use config. members. push ({}) to add nodes;


Other methods:

3.2 failover and recovery are the process of restoring the replica set to the original state after the fault. There are two types of faults to be handled. The first type includes all non-destructive faults. Simply restart the service. The second is to clarify the fault, mainly because the data file is damaged. Otherwise, the mongodb service is shut down. If the host name and port number are not changed, re-execute the data folder and synchronize the data after the startup. If you modify attributes, you must use rs. reconfig ();
3.3 The deployment policy replica set contains a maximum of 12 nodes. The configuration of the minimum replica set that provides automatic failover is shown in the previous example. Contains two copies and one arbitration node. In the production environment, the arbitration server node can run on the application server, while the copy runs on its own machine. For most environments, this configuration is both economic and university-level.