MongoDB Shard Configuration Series One:

After this blog:

Http://www.cnblogs.com/xiaoit/p/4479066.html

The installation process is no longer described here.

1: Introduction to Shards

The Shard is a kind of database cluster system that expands the massive data horizontally, the data table is stored on each node of sharding, and the user can easily construct a distributed MongoDB cluster by simple configuration. The data chunking of MongoDB is called Chunk. Each chunk is a contiguous data record in the collection, usually with a maximum size of 200MB, and a new chunk is generated beyond that.

2:

Configuring MongoDB's sharding cluster requires 3 roles:
A:shard Server
Shard Server is the Shard that stores data, each Shard can be an instance, or it can be a replica set. To achieve auto-failover within each shard, the official recommendation is that each shard be a set of replica.
B:config Server
In order to store a particular collection in multiple shard. You need to specify a shard key for collection, such as {Age:1}.shard key, which determines which shard the data resides in. Config Server is the configuration information used to store all shard nodes, the distribution of shards, the sharding configuration information for all the DB and collection in the cluster.
C:route Process
This is a front-end routing process in which the client enters. Then ask the config server which shard to query or save records? The corresponding Shard is then connected to the operation, and the result is returned to the client. The client simply sends the original MONGOD query or update request to route process. Don't worry about which shard the document is stored on.

Simulating environment configuration shards on a single machine
Shard Server 1:27,017
Shard Server 2:27,018
Config server:27019
Route process:40000

3: Create data directory and ensure read and write permissions

Mkdir-p./DATA/SHARD/{S01,S02}

4: Start shard Server1:

[[email protected] mongodb]#./bin/mongod--port 27017--dbpath./data/shard/s01--logpath./log/s01--forkabout to fork C Hild process, waiting until server is a ready for connections.forked Process:54045child process started successfully, Paren T exiting

　　

Start Shard Server2:

[[email protected] mongodb]#./bin/mongod--port 27018--dbpath./data/shard/s02--logpath./log/s02--forkabout to fork C Hild process, waiting until server is a ready for connections.forked Process:54065child process started successfully, Paren T exiting

　　

Start Config Server

[Email protected] mongodb]# mkdir-p/data/shard/config[[email protected] mongodb]#./bin/mongod--port 27019--dbpath. /data/shard/config--logpath./log/configlog--forkabout to fork child process, waiting until server was ready for CONNECTI Ons.forked Process:54111child Process started successfully, parent exiting

Note: We can start the same as the normal Mongod service and do not need to add the-shardsvr and Configsvr parameters. Since the function of the two parameters is to change the boot port, we can specify the port on our own.

Start Route Process

[Email protected] mongodb]#/bin/mongos--port 40000--fork--logpath/data/shard/route.log--chunksize 1--configdb Lo calhost:270192015-05-05t01:28:04.996-0700 warning:running with 1 config server should is done only for testing purposes a ND is not recommended for Productionabout to fork child process, waiting until server is a ready for connections.forked proc Ess:54169child process started successfully, parent exiting

ChunkSize: Specifies the size of the chunk, which defaults to 200M. For convenience the test is specified as 1M. This means that when the data inserted in this shard is larger than 1M, data transfer begins.

5: Configure Sharding

The direct connection to the MONGOs routing process is now

　　

Note here we have to pay attention to the selection of the chip key, select the chip key needs according to the specific business data form to choose, must not arbitrarily choose, in fact, in particular do not choose self-increment _id as a key, unless you are very clear about the purpose of doing so, according to experience recommend a more reasonable chip key way, "self-increment field + It is also explained here that the basic mechanism of sharding is that shards always attempt to distribute existing data across all shards. For example, now there are two shards, I have chosen the ID as the chip key, assuming that the ID is self-increment, such as 1--10000, then the result of the Shard is evenly divided, that is, 1--5000 in the chip a,5000--10000 in piece B, of course, not necessarily so accurate, but it is guaranteed to be as average as possible, And so on, if there are three shards, equally evenly divided. It is also necessary to note that when the data is inserted at the beginning, the data is inserted only on one piece of the Shard, after inserting, the inside of MongoDB begins to move the data between the slices, this process may not be immediate, and MongoDB is smart enough to decide whether to move immediately or later depending on the current load.
After inserting the data, execute Db.users.stats () immediately, and two times can be verified as stated above.

MongoDB Shard Configuration Series One: