About MongoDB high Availability cluster architecture

In the age of big data, traditional relational databases need to be able to have higher services to solve the challenges of high concurrency and read-write, efficient storage of massive data, high scalability and high availability. But it is because of these problems that NoSQL was born.

Blog post from 严澜-"How to build efficient MongoDB cluster"

NoSQL has these advantages:

2. Large data volumes can be easily freed from traditional MySQL single-table storage-scale limits by storing large amounts of data from inexpensive servers.
4. High scalability, NoSQL removed the relational database relational features, it is easy to scale horizontally, out of the past always vertical expansion of the criticism.
6. High performance, NoSQL gets the data in a simple key-value way, very fast. And NoSQL caches are record-level, a fine-grained cache, so NoSQL has a lot of performance at this level.
8. Flexible data model, NoSQL can store custom data formats at any time without having to create fields in advance for the data to be stored. In the relational database, adding or deleting fields is a very troublesome thing. If it is a table with very large amounts of data, adding fields is simply a nightmare.
10. Highly available, NoSQL can easily implement a highly available architecture without compromising performance. For example, MongoDB can quickly configure a highly available configuration with MONGOs, MONGO shards.
12. In a NoSQL database, most queries are the way key-value pairs (key, value) are. MongoDB is a product between relational and non-relational databases, most like relational databases in non-relational databases. Supports an object-oriented query language that can achieve almost the most functionality of a relational database single-table query, and also supports indexing of data.

(MongoDB high-availability cluster architecture)

First, MONGOs

The entrance to the database cluster request, all requests are coordinated through MONGOs, do not need to add a route selector in the application, MONGOs itself is a request distribution center, it is responsible for the corresponding data request request forwarded to the corresponding Shard server. In a production environment there is usually more mongos as the entrance to the request, preventing one of the other MongoDB requests from being hung out of operation.

second,config server

As the name implies, configure the server to store the configuration of all database meta information (routing, sharding).

The mongos itself does not have a physical storage Shard server and data routing information, but is cached in memory, and the configuration server actually stores the data. MONGOs the first boot or shutdown reboot will load configuration information from config server, and if configuration server information changes will notify all MONGOs to update their status, so that MONGOs can continue to route accurately. In a production environment there are usually multiple config server configuration servers, because it stores the metadata of the Shard route, this can not be lost! Even if you hang one of them, as long as there is inventory, the MongoDB cluster will not hang off.

Third , replica set replica set

in MongoDB, the master-slave mode is actually a single copy of the application, not very good extensibility and fault tolerance. A replica set with multiple replicas guarantees fault tolerance, and resolves the first problem above: "The primary node is hung, and the entire cluster is automatically switched."

The client connects to the entire replica set and does not care about which machine is hung. The primary server is responsible for reading and writing the entire replica set, the replica set synchronizes the data backup periodically, once the master node hangs, the replica set is detected through the heartbeat mechanism, it will initiate the election mechanism of the master node within the cluster, and automatically elect a new primary server, all of which are transparent to the application server.

four, Shard Shard

reduce hard disk reads and writes, network IO, CPU, and memory bottlenecks by Collection1 1T of data stored in one data table in a single node to 4 machines. As long as the Shard rule is set up in the MongoDB cluster, the corresponding data operation request can be forwarded to the corresponding Shard server automatically by MONGOs operation database. It is reasonable to set the slice key in the production environment, which affects how to divide the data evenly into multiple shard servers.

About MongoDB high Availability cluster architecture