Learn MongoDB by creating sharded cluster step by step

MongoDB is one of the most widely used NoSQL (not-only SQL) engines in the world, ranking very well above the db, and is the May ranking:

　　

You can see that the previous four are traditional relational databases, and MongoDB is the first in NoSQL. This article will briefly describe some of the features of MongoDB, and then learn MongoDB by building sharded cluster in the Linux environment step by step. The MONGODB experiment in this article is mongodb3.0 and may differ slightly from the latest version (mongodb3.4) in detail.

MongoDB features the official Word can summarize the characteristics of MongoDB:

MongoDB is a Open-source document database that provides high performance, high availability, and automatic Scali Ng.

Open source, document-based oriented, high performance, high availability, auto scaling.

　　Open Source :

This benefit does not have to say, GitHub has the source code.

　　 Document oriented: The document has a similar data structure in many programming languages, with various table, map, Dict, and no longer use DAO (data Access Object).      For example, in Python, the document corresponds to the dict, and the array corresponds to the list.　　Document also supports nested document and array, which in turn can partially resolve the associated query (although putting the relevant information in a nested document reduces the cost of the associated query, but in some cases it is a bit of a headache to have a correlation query) Because of document-based, so the schema free (mode freedom), the use of relational data of the students know that the online modification of the table structure is a very troublesome thing. But in MongoDB, it is too easy to delete a field, this is also the last thing developers like, such as the game server, the player's persistent data will change constantly, each update will add some features, but also add some need to persist the field, with MongoDB is very appropriate. High Performance: Support for nested document, the time-consuming operation of Federated query in relational database, a query in MongoDB can handle rich index support, and the index also supports nested documents and arrays in the case of using the sharding mechanism, read and write operations can be routed to different Shard , referring to the concurrency performance of the cluster Highly Available: To make MongoDB highly available, you have to use MongoDB's replication mechanism: Replica set replica set with asynchronous replication (asynchronous replication) and automatic failover for availability The replica set is specifically introduced later Auto Scale (split horizontally): In relational data, database throughput is generally referred to by vertical or horizontal tables when the amount of data in a single table is too large. In MongoDB, Sharding is one of its core functions, providing automatic horizontal scaling (horizontal scalability) to split a large collection of data, sharding different subsets of the same set of data on different machines.　　When the application chooses the proper sharding key, the read and write operation can be routed to a shard, which greatly improves the cluster throughput performance.　　The following will be devoted to the composition of sharding cluster. This article does not cover the basics of MongoDB, but in order to introduce sharding knowledge later, and to build sharded cluster, here is a special field for _id (field) By default, MongoDB creates a unique index on the _id field of the collection.　　If you do not include _id in the persisted document, MongoDB will automatically add this field, whose value is a objectid. MongoDB officials recommend that _id use Objectid, or natural unique identifier (unique), to speak of a self-increasing number, or UUID.　　_ID is specific in sharding-related crud, and can be used for documentation.　　In addition, for the convenience of later descriptions, here are several concepts in MongoDB DB: corresponding to MySQL DB collection, set: Table corresponding to MySQL document: corresponding to the record of MySQL replica set　　MongoDB provides high availability through replica set (replica set): Redundancy and automatic failover. Replication sets are said to be multi-split copies of the same dataOn different machines (or even in different data centers) to improve fault tolerance. A typical replica set consists of a set of Mongod instances, with only one node providing write operations, called Primary,primary, which is also the default read node. Also, the replica set can contain one to multiple secondary nodes, and the secondary node provides only read operations. As shown in the following:

The application is connected by driving to the primary, all writes are performed on the primary, and primary writes the operations to Oplog (operation Log), secondary by asynchronously replicating Oplog, Then perform the operations on the Oplog on the local dataset, thus achieving the consistency of the data. As can be seen from here, although secondary and primary maintain the same data, the change is later than primary.

If the application to the real-time data requirements are not too high, such as comment data, aggregated data, and so on, it can be read from secondary, so that can be read-write separation and high concurrency. 　　If the copy is placed in a different data center, it can better provide data locality (locality) and the availability of distributed services. We see that if a secondary does not work properly (possibly process crash, physical corruption, network failure), it has little impact on the application. But what if primary can't work?　　This time MongoDB automatic failover began to play a role. There is a heartbeat (heartbeat) between the used Mongod nodes in the replica set, and if the other nodes do not receive a primary heartbeat for a certain amount of time, then the primary is considered dead. can be electedSecondary will vote for the new primary. The entire process is as follows:

The automatic failover ensures high availability of MongoDB, but during the switchover from primary to secondary, MongoDB is unable to provide write operations during this period of time. The performance is that the database operation request for the application will return some errors, this time the application needs to identify these errors, and then do a retry.

　　

In addition to primary and secondary, there can be another node in the replica set: Arbiter. The difference between the arbiter and the secondary node is that arbiter does not persist data (do not bearing), and it is not natural to be elected when primary is hung up. Arbiter's role is to vote: In order to elect a new primary,secondary voting rule is the minority obey the majority, if the number of nodes in replica set is even, then there may be a "draw" situation, So adding a arbiter can solve the problem at the lowest cost.

Arbiter does not persist data, so it takes up less disk space and does not require a high level of hardware.　　The official recommendation is that arbiter not be placed on the same physical host as primary or secondary. In a later demonstration, a arbiter is also added to the replica set to reduce disk usage. sharded Cluster

The so-called sharding is the distribution of different subsets of the same set to different machines (shard), MongoDB uses the sharding mechanism to support the large amount of data, the different crud routes to different machines to execute, and the throughput performance of the database is mentioned. This shows that sharding is a very common scale out method.

　　

As shown, a set (Collection1) has 1 t of data, originally placed in a separate database, through Sharding, the collection of data in four separate Shard, each shard store this set of 256G of data. Each shard is physically a separate database, but logically together to form a database.

A sharded cluster consists of three parts: Config server,shards,router. ：

　　

　　Shards:

Stores the data, either as a single mongod or as a replica set. In a production environment, replica set is used to improve high availability. The data stored on the Mongod is chunk as the base unit, with a default size of 64M, followed by a split (split) and migration (migration) of data on Shard.

　　Config server:

Storage cluster metadata (metadata), that is, which part of the data is placed on which Shard, router will use these metadata to distribute the request to the corresponding shards, shards migration is also controlled by config server.

　　Router:

The MONGOs instance, which serves the application directly in a cluster, leverages the metadata on the config server to create the best query plan.

Data partition:

As previously known, MongoDB collection at this level of data, called sharding. The minimum granularity of a block is chunk, and its size (chunkSize) defaults to 64M.

When the amount of data in a collection exceeds chunksize, it is split into two chunk, a process called splitting. So according to what principle to split a chunk data into two chunk, this is the role of sharding key, sharding key is indexed field, through the Sharding key, you can divide the data into two chunk, Each document on which chunk, this is the metadata information. Metadata information is stored on the config server for easy router use.

If there are multiple shard in the sharding cluster, then the number of chunk on different shard may be inconsistent, and there will be a background process (balancer) to migrate (migrate) chunk, Migrate from the Shard with the largest number of chunk to the chunk with the lowest number of chunk until a balanced state is reached. The process of migration is transparent to the application.

As shown, there are 3 chunk on Sharda Shardb before migration, and there is only one chunk on Shard c. By migrating a chunk from Shardb to SHARDC, a balanced state is achieved.

The goal of splitting and migration is to distribute data evenly across the shards, with the fundamental objective of distributing the crud operations of the data to each shard in a balanced manner, improving the concurrency of the cluster.

　　

sharded Cluster Build statement, this section is just to demonstrate the sharded cluster build process, and production environment is still a big difference, but I will try to point out these differences in the text.　　The first thing to note is that the demonstration in this article does not involve authentication (--auth), but in the production environment is very important to authentication, I believe you can remember the Chinese New Year MongoDB was hijacked, attacked events. As mentioned earlier, a typical sharded cluster includes router (mongos), config server, and shards, each of which can be shard (single point) or a copy set (standalone set). the next demo includes a router, three config server, two shard. Each shard has a primary, a secondary, and a arbiter composed of replica set. Before you begin, first predefine all the variables you need to use, as follows:

1#!/bin/Bash2Export bin_home=/usr/local/mongodb/bin3Export db_path=/home/mongo_db/Data4Export log_path=/home/mongo_db/Log5 6Local=127.0.0.17 8 #config rs9Export Rs1_1_db_path= $DB _path/rs1_1TenExport Rs1_2_db_path= $DB _path/rs1_2 OneExport Rs1_3_db_path= $DB _path/rs1_3 AExport Rs2_1_db_path= $DB _path/Rs2_1 -Export Rs2_2_db_path= $DB _path/rs2_2 -Export Rs2_3_db_path= $DB _path/Rs2_3 the  -Export rs1_1_db_log= $LOG _path/Rs1_1.log -Export rs1_2_db_log= $LOG _path/Rs1_2.log -Export rs1_3_db_log= $LOG _path/Rs1_3.log +Export rs2_1_db_log= $LOG _path/Rs2_1.log -Export rs2_2_db_log= $LOG _path/Rs2_2.log +Export rs2_3_db_log= $LOG _path/Rs2_3.log A  atExport rs1_1_port=27018 -Export rs1_2_port=27019 -Export rs1_3_port=27020 -Export rs2_1_port=27021 -Export rs2_2_port=27022 -Export rs2_3_port=27023 in  -Export rs1=rs1 toExport rs2=rs2 +  - #config Config_server theExport Conf1_db_path= $DB _path/Db_conf1 *Export Conf2_db_path= $DB _path/Db_conf2 $Export Conf3_db_path= $DB _path/db_conf3Panax Notoginseng  -Export conf1_db_log= $LOG _path/Conf1.log theExport conf2_db_log= $LOG _path/Conf2.log +Export conf3_db_log= $LOG _path/Conf3.log A  theExport conf1_port=40000 +Export conf2_port=40001 -Export conf3_port=40002 $  $Export conf1_host=$LOCAL: $CONF 1_port -Export conf2_host=$LOCAL: $CONF 2_port -Export conf3_host=$LOCAL: $CONF 3_port the  - #config Route_serverWuyiExport route_db_log= $LOG _path/Route.log the  -Export route_port=27017

These commands can be executed once in the session window, but the better way is to save them in a file (such as mongodb_define.sh) and then execute the file:source mongodb_define.sh

Starting shards (replica set) in this section, two replica sets are created, respectively Rs1, rs2. Each replica set contains three nodes, and one of them is arbiter. Since the two replica set creation process is no different, take rs1 as an example. For the construction of the replica set, see the Deploy-replica-set-for-testing section of the MongoDB doc, which is quite clear. Step1: First you have to create a directory that holds the data:mkdir-p $RS 1_1_db_pathmkdir-p $RS 1_2_db_path 　　 mkdir-p $RS 1_3_db_pathPS:-P means "no error if existing, make parent directories as needed" Step2: Start the three mongod that make up the rs1

$BIN _home/mongod--port $RS 1_1_port--dbpath $RS 1_1_db_path--fork--logpath $RS 1_1_db_log--replset $RS 1--smallfiles-- Nojournal
$BIN _home/mongod--port $RS 1_2_port--dbpath $RS 1_2_db_path--fork--logpath $RS 1_2_db_log--replset $RS 1--smallfiles-- Nojournal
$BIN _home/mongod--port $RS 1_3_port--dbpath $RS 1_3_db_path--fork--logpath $RS 1_3_db_log--replset $RS 1--smallfiles-- Nojournal

With regard to the startup option of Mongod, you can view it through Mongod--help, in the command line above,--replset specifies the name of the replica set, and the--smallfiles declaration uses a smaller default file,-- Nojournal indicates that the journaling mechanism is not turned on. Note that in this place does not open journaling because the experimental environment disk space is limited, and all the Mongod instances are on this machine, in the build environment, must start journaling, this is the guarantee of MongoDB durability. Step3: Initialize replica set rs1 in this step, you need to connect to any node of the replica set through MONGDB client MONGO, initialize the replica set, and connect to Rs1_1 (Port 27018):MONGO--port $RS 1_1_portLet's take a look at the status of the replica set now (PS: All command lines that start with > are represented in the MONGO this interactive client input Directive) > Rs.status () can see that this replica set has not been initialized >config = {

_id: "Rs1",
Members: [
{_id:0, Host: "127.0.0.1:27018"},
{_id:1, Host: "127.0.0.1:27019"},
{_id:2, Host: "127.0.0.1:27020", arbiteronly:true},
]
}

>rs.initiate (config)

As can be seen from Config and post-run replication set state, the Rs1_3 (127.0.0.1:27020) Mongod is a arbiter that participates only in voting and does not persist data.　　In addition Rs1_1 for primary, rs1_2 for secondary.  　　So far, the replica set RS1 is up. For the start of S2, all commands are given below. Easy Reader Practice

Mkdir-p $RS 2_1_db_path
Mkdir-p $RS 2_2_db_path
Mkdir-p $RS 2_3_db_path

$BIN _home/mongod--port $RS 1_1_port--dbpath $RS 1_1_db_path--fork--logpath $RS 1_1_db_log--replset $RS 1--smallfiles-- Nojournal
$BIN _home/mongod--port $RS 1_2_port--dbpath $RS 1_2_db_path--fork--logpath $RS 1_2_db_log--replset $RS 1--smallfiles-- Nojournal
$BIN _home/mongod--port $RS 1_3_port--dbpath $RS 1_3_db_path--fork--logpath $RS 1_3_db_log--replset $RS 1--smallfiles-- Nojournal

MONGO--port $RS 2_1_port
>config = {
_id: "Rs2",
Members: [
{_id:0, Host: "127.0.0.1:27021"},
{_id:1, Host: "127.0.0.1:27022"},
{_id:2, Host: "127.0.0.1:27023", arbiteronly:true},
]
}
>rs.initiate (config)

Start config servers

MongoDB officially recommends that config server be composed of three mongod instances, each mongod preferably on a different physical machine. This three Mongod is not a copy-set relationship,

　　Step1: Creating a DB Directory

Mkdir-p $CONF 1_db_path
Mkdir-p $CONF 2_db_path
Mkdir-p $CONF 3_db_path

　　Step2: Launch three Mongod instances:

$BIN _home/mongod--port $CONF 1_port--dbpath $CONF 1_db_path--fork--logpath $CONF 1_db_log--configsvr--smallfiles-- Nojournal
$BIN _home/mongod--port $CONF 2_port--dbpath $CONF 2_db_path--fork--logpath $CONF 2_db_log--configsvr--smallfiles-- Nojournal
$BIN _home/mongod--port $CONF 3_port--dbpath $CONF 3_db_path--fork--logpath $CONF 3_db_log--configsvr--smallfiles-- Nojournal

The same start parameter nojournal only to save storage space, in the production environment must use journaling. Unlike the startup of Mongod when creating replica set, there is a configsvr option that indicates that these nodes are present as Config server.

After starting these three mongod, there will be no such operations as replica set, such as three mongod bindings, and it also shows that config server is independent of each other.

Start router in sharded cluster, router (mongos) is an application-connected object, and all operations to MongoDB are routed through router Step1: Start MONGOs$BIN _home/mongos--port $ROUTE _port--configdb $CONF 1_host, $CONF 2_host, $CONF 3_host--fork--logpath $ROUTE _db_log --chunksizeNote that the executable program here is MONGOs, not the previous Mongod, and can also be viewed through MONGOs--help for parameters. In the above command, the--CONFIGDB option specifies three config server,--chunksize that specifies the size of the chunk, in units of M. With respect to chunksize, the default is 64M, although you can specify chunksize at the first boot, but MongoDB is officially recommended to modify it in the following way.　　The purpose of chunksize in this paper is to make it easier to observe the data splitting and migration in the later experiments. Chunksize in fact will persist into config.setting, connected to MONGOs to view: MONGO--port $ROUTE _port

As you can see in the blue box above, there is no shard information now, because config servers has nothing to do with replica set until now.

Step2: Add the two replica set (Rs1 rs2) created earlier to the sharded clusterMONGO--port $ROUTE _port

Mongos> sh.addshard (' rs1/127.0.0.1:27018 ')
Mongos> sh.addshard (' rs2/127.0.0.1:27021 ')

PS: Why you need to specify a Mongod IP port behind Rs1, this is to find the corresponding Mongod, and then find the corresponding RS

See the results again:

You can see that two shard have been added, each of which is a replica set. 　　It is interesting that arbiter (such as rs1_3) does not appear in the query results, possibly because Arbiter does not persist the data and is not meant to be displayed here. So far, the whole sharded cluster even set up, but not yet into the real use stage, to play sharded cluster role, we have to specify which collection can be sharding, And how to sharding create Sharding key

To demonstrate, we assume that adding a db called test_db, which has two collection, one that needs sharding, is called Sharded_col, and the other temporarily does not have sharding, called Non_sharded_col, Of course, you can add new collections later, or change the set of non-sharding to sharding.

You need to log in to Router: MONGO--port $ROUTE _port

　　Step1: First you have to tell MongoDB test_db this database supports sharding

Mongos> sh.enablesharding ("test_db")
{"OK": 1}

You can check the status of the database at this time, note that it is the databases collection below the Config db

mongos> use Config

Mongos> Db.databases.find () {"_id": "admin", "partitioned": false, "PRIMARY": "config"} {"_id": "test_db", "PA Rtitioned ": True, " primary": "Rs1 "As you can see from the query results, TEST_DB is supported for sharding ("partitioned": true). In addition to the upper part of the primary:rs1, this primary and replica set inside the primary is not the same thing, here primary is primary shard meaning, we know that even in sharded cluster environment, Some data volumes are less fragmented than smaller db, which is stored on primary shard by default Step2: For the required collection (that is, Sharded_col here) specify Sharding key before the role of Sharding Key has been mentioned, the choice of sharding key, is a more complex problem, sharding key to the index, There are a number of limitations to the operation of CRUD statements, which are later detailed, where _id is used by default to do sharding key (_id is the index that MongoDB adds to each collection by default) mongos> sh.shardcollection (' Test_ Db.sharded_col ', {' _id ': 1}) Next look at the status of the entire sharded cluster:

　　

The content of the Sh.status () reaction is actually from the content of the whole database of config, but does a certain degree of integration. As can be seen from the above, there are two shard,rs1, rs2;test_db allow Sharding,test_db.sharded_col the entire collection sharding key for {"_id": 1}, And at present there is only one chunk rs1 the whole shard.

Summarize:

So far, we have built a sharded cluster with three config servers and two shard, each of which contains a replica set of three nodes, and each contains a arbiter. We can look at the size of the data persisted by each Mongod instance just after it was created:

　　

As you can see, two arbiter (Rs1_3, Rs2_3) occupy a much smaller space.

For applications, the cluster (sharded cluster) and single point (standalone) are somewhat different, if you need to play sharded cluster high performance, high availability, you need to carefully select the Sharding key according to the application scenario, The selection of Sharding key is closely related to the establishment of the index and the CRUD statement, which is discussed later. For this example of the current build, simple test, insert enough document to Sharded_col to see chunks split and migration.

References

DB engines

The-id-field

Replication-introduction

Deploy-replica-set-for-testing

Deploy-shard-cluster

Learn MongoDB by creating sharded cluster step by step