About Windows platform Building MONGO database replication Set this topic, I have written two blog posts in front
First article: How to build a MONGO database replica set on the Windows platform
Second: Data synchronization and fault adaptive testing
In this article, let's focus on the replication set, and analyze how it works
First, common scenarios
Loss of network connectivity between application and database
Scheduled outages, power outages, database service hard drive failures, and more
Replication can fail over and replication allows you to balance read loads between replicas, keeping replication nodes in sync with the primary node
Second, the principle of work
The replica set relies on two basic mechanisms: Oplog and Heartbeat (Heartbeat). Oplog makes it possible to replicate data, while "heartbeat" monitors health conditions and departs failover;
2.1 About Oplog
Oplog is the key to MongoDB replication, Oplog is a fixed collection, located in the local database of each replication node, records all changes to the database, each time the client writes data to the primary node, it automatically adds a record of love to the oplog of the master node. One of the blogs has enough information to reproduce the data. Once the write operation is copied to a slave node, a record is also saved from the Oplog of the node.
All replica set metadata and Oplog are saved in the local database because they cannot be copied;
So we're looking at oplog in detail.
Note here that each slave node has its own oplog, which is applied immediately from the node using long polling to the new entry of the autonomous node Oplog. If the Plex node cannot find the point in the master node's oplog that it wants to synchronize, then the replication will stop permanently. This is the following exception in the log:
Replcation data too stale, halting
Caught Syncexception
Adjust the size of the Oplog, use command Db.getreplicationinfo () to see how much oplog space is allocated, and use the following command to change the default Oplog size
2.2 Heartbeat detection and failover
The heartbeat detection of the replica set helps in the election and failover. By default, each replica set member pings the other members every 2s. This way the system can understand its health. Running Rs.status () can also see the health status.
Note: In three nodes, if two slave nodes are killed, the log on the master node will be as follows:
Replset can ' t see a majority of the set,
Replset Secondary
It means that without the majority node, the master node will downgrade itself to the slave node;
Third, management
Since there are many potentially complex configuration items in the replica set, we'll cover these complex configuration items in more detail next.
3.1 Configuration details You can initialize the collection of replicas with the rs.initiate () and Rs.add () methods. Use Config.members.push ({}) to add nodes;
A few other ways:
3.2 Failover and recovery recovery is the process of restoring a replica set to its original state after a failure. There are two major types of failures that need to be addressed. The first category is to include all the non-destructive faults, just restart the service. The second is clear fault, mainly data file corruption, and so on, the non-normal shutdown MongoDB service, if you do not change the host name and port number to re-execute the Data folder, after starting data synchronization. If the property is modified, use Rs.reconfig ();
3.3 The deployment policy replica set contains a maximum of 12 nodes, and the minimum replica collection configuration that provides automatic failover is in the previous example. Consists of two replicas and one quorum node. In a production environment, the arbiter node can run on the application server, while the replica runs on its own machine. For most environments, this configuration
"MongoDB" Windows platform build MONGO database replica set (cluster-like) (iii)