Preliminary research on MongoDB database cluster

1. Testing principle

——————————————————————————————————

1. Introduction to Sharding cluster

This is a horizontally scalable model with excellent performance when the amount of data is large. Actual large-scale applications generally use this architecture to build mongodb systems.

To build a MongoDB Sharding Cluster, three roles are required:

Shard Server: mongod instance, used to store actual data blocks, a shard in the actual production environment
The server role can be assumed by several machines forming a replica set to prevent a single point of host failure.

Config Server: mongod instance, which stores the entire Cluster Metadata, including chunk
information.

Route Server: mongos
Instances, front-end routing, clients access from this, and make the entire cluster look like a single database, so that front-end applications can be used transparently.

Sharding architecture diagram:

2. Description of this test environment

Install centos5.6+MongoDB1.9.1 on 4 machines

The IP addresses are: 192.168.3.4, 192.168.3.21, 192.168.3.29, 192.168.3.79

The replica set1 port is 3500

Replica set2 port is 3600

The config server port is 5000

The mongos port is 5500

1. Run a mongod instance on two machines respectively, organized as replica set1, as node1 of the cluster.

2. Then run a mongod instance on two machines respectively, organized as replica set2, as node2 of the cluster.

3. Run a mongod instance on three machines respectively as three config servers.

4. Use a machine to run a mongos process for client connection.

Create a new test database and c1 collection for testing, and enable shards support for the database and collection.

Test the inserted data, the results are as follows:

The above status information shows that the c1 collection has successfully opened shards and inserted data. “n1, n2” in the figure are the shards code names.

2. Test content

——————————————————————————————————

1. Test the situation after a single node in the replica set is down

The picture below shows the status before down machine:

The test method is to kill the left host and check whether the right host will automatically compete to become “PRIMARY”. The result is as follows:

Analyzing the above logs, we learned that when killing the replica
After the original primary host is added to the set, the original secondary host will not actively become the primary host. Try to restart the killed process, the result is as follows:

The results show that in a replica consisting of 2 nodes
In set, after the primary host goes down, the scondary will not automatically become the primary. After the killed process is restarted, the original secondary host will
can become the primary, and its log also clearly shows that when the 192.168.3.4:3500 process restarts, it believes that another member should be “elected” out, so the original secondary host
Just became primary.
Analyzing the reasons, we can understand that replica
The “PRIMARY” in the set is generated through “election”, and this election needs to be initiated by the host called “majority”, so the original secondary did not become
The reason for primary is that it finds that there is no majority in the set, so the “election process” cannot proceed. After rebooting at 192.168.3.4:3500, election starts
At the beginning, 192.168.3.21:3500 (original secondary) was elected as “PRIMARY”.

2. Test the situation after single node and multiple nodes are down in the config server

Only close config3 (192.168.3.29:5000), test that writing data is normal and reading data is normal.

Close config2(192.168.3.21:5000) and config3(192.168.3.29:5000), test that writing data is normal and reading data is normal.

Close allAfter config, the database cannot be opened.

3. Test the situation after a single shard group is down

After closing the 3500 and 3600 port processes in shard2, the database can be read, but cannot be written.