"MongoDB" Windows platform builds MONGO database replica set (cluster-like)

Original link: "MongoDB" Windows platform build MONGO database replica set (similar cluster) (i)

Replica sets (replica set) is a new feature that starts with the mongodDB1.6 version, which enables automatic failover and automatic repair of feature member nodes, and the data between each db is exactly the same, greatly reducing the risk of a single point of failure.

【】

This is the replica set schema for three nodes. The figure is from the book "The Essentials of MongoDB Management and development" written by Red pill. As can be seen, the structure is similar to a cluster, in fact, can be regarded as a cluster. Because it does have the same effect as the cluster implementation.

First, deploy replica sets.

Next shows how to demonstrate the deployment of a 3-node replica on a single server sets

Second, start replica service

Open three command Windows respectively, and then perform the following three sentences, respectively.

[HTML]View PlainCopy  

2. Mongod.exe--replset rs1--keyfile "D:\Program files\mongodb\data\replica\key\r0"--port 28010--dbpath "D:\Program File S\mongodb\data\replica\data\r0 "--logpath" D:\Program files\mongodb\data\replica\log\r0.log "--logappend
8. Mongod.exe--replset rs1--keyfile "D:\Program files\mongodb\data\replica\key\r1"--port 28011--dbpath "D:\Program File S\mongodb\data\replica\data\r1 "--logpath" D:\Program files\mongodb\data\replica\log\r1.log "--logappend
12. CD/D D:\Program Files\mongodb\bin
18. Mongod.exe--replset rs1--keyfile "D:\Program files\mongodb\data\replica\key\r2"--port 28012--dbpath "D:\Program File S\mongodb\data\replica\data\r2 "--logpath" D:\Program files\mongodb\data\replica\log\r2.log "--logappend

Third, login client, initialize replica sets environment

"MongoDB" Windows platform build MONGO database replica set (similar cluster) (ii)

In our previous blog, we focused on how to build a MongoDB replica set under the Windows platform. Detailed Blog Address:

As space is limited in the previous article did not verify the results, in this blog we mainly test:

Through the Rs.status () command we can query to each node to run normally.

First, the data synchronization test

Insert on port 28011, 28012:

View reason: Find the answer online

First of all this is normal, because secondary is not allowed to read and write, in the application of writing more than read, using the replica sets to achieve read and write separation. By specifying Slaveok at the time of connection, or by specifying the secondary in the main library, the pressure of reading is shared by the primary and only the write operation is assumed. The secondary node in the replica set is not readable by default.

See details: Http://stackoverflow.com/questions/8990158/mongdodb-replicates-and-error-err-not-master-and-slaveok-false-code

Second, fault adaptive testing

When the main library stops heartbeat at the time of Detection, 28012 elect itself as the main library, see below:

28012 the above can be inserted:

28011, it's still not plugged in.

"MongoDB" Windows platform build MONGO database replica set (cluster-like) (iii)

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

[HTML]View PlainCopy 

1. Mongod.exe--replset MyApp--oplogsize 1024

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; some other methods: 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) (GO)