[MongoDB] mongodb sharded cluster (iii) on windows platform, mongodb Cluster

[MongoDB] mongodb sharded cluster (iii) on windows platform, mongodb Cluster

In the previous two blogs, we elaborated on the working principle and building process of the sharded cluster. In this blog, we will analyze the testing results of the sharded cluster;

First, check the status of the sharded cluster. We can see that replica set A and replica Set B are normal:

1. Enable the sharding set

Enable sharding for a database. This is a prerequisite for sharding for any set. Assume that the test database is slidetest.

 

Note: It looks a bit similar to the index definition, especially the unique key. When sharding is performed for an empty set, mongodb creates an index for each shard. You can directly link the parts and run getIndexs () for verification. You can log on to 3000 to view the information.

 

 

Ii. Write to sharded Cluster

Once the sharding of the set is completed, the sharding cluster is ready. You can now write data to the cluster, which is distributed to each shard.

Initialize data on 4000:

For (var I = 0; I <200; I ++) {db. spreadsheets. insert ({"filename": "sheet-" + I, "updatedate": new Date (), "username": "Alberta shao", "data ": "abcde" * 1000 })}

View results:

 

Next we will check what happened to the entire block. We can see that there are two blocks, and their maximum values are different.

Note: $ minKey and $ maxkey are commonly used in comparison operations as BSON boundary. $ Minkey is always light rain on all BSON types, while $ maxKey is always larger than all BSON types .. MongoDB uses these two types to compare the block endpoints

Insert data. Assume that 0.2 million records are inserted,

mongos> sh.status()--- Sharding Status ---  sharding version: {        "_id" : 1,        "version" : 4,        "minCompatibleVersion" : 4,        "currentVersion" : 5,        "clusterId" : ObjectId("545d9af5340aec0c2272afda")}  shards:        {  "_id" : "shard-a",  "host" : "shard-a/WIN--20141018KO:3000,WIN--20141018KO:3001" }        {  "_id" : "shard-b",  "host" : "shard-b/WIN--20141018KO:30100,WIN--20141018KO:30101" }  databases:        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }        {  "_id" : "slidetest",  "partitioned" : true,  "primary" : "shard-a" }                slidetest.spreadsheets                        shard key: { "username" : 1, "_id" : 1 }                        chunks:                                shard-b 1                                shard-a 2                        { "username" : { "$minKey" : 1 }, "_id" : { "$minKey" : 1 } } -->> { "username" : "albertshao", "_id" : ObjectId("545df80537216b1577de0251") } on : shard-b Timestamp(2, 0)                        { "username" : "albertshao", "_id" : ObjectId("545df80537216b1577de0251") } -->> { "username" : "albertshao", "_id" : ObjectId("545e062437216b1577de1802") } on : shard-a Timestamp(2, 2)                        { "username" : "albertshao", "_id" : ObjectId("545e062437216b1577de1802") } -->> { "username" : { "$maxKey" : 1 }, "_id" : { "$maxKey" : 1 } } on : shard-a Timestamp(2, 3)mongos>

As shown above, usename is used as the block partitioning key. At the same time, it can be seen that there are three blocks above, of which shard-a has two blocks and shard-B has one.

We can see the database migration through changelog:

mongos> db.changelog.count({what:"split"})2mongos> db.changelog.count({what:"moveChunk.commit"}).count()2014-11-08T20:12:09.618+0800 TypeError: Object 1 has no method 'count'mongos> db.changelog.find({what:"moveChunk.commit"}).count()1mongos> db.changelog.find({what:"moveChunk.commit"}){ "_id" : "WIN--20141018KO-2014-11-08T11:01:40-545df8141603dfc967d0fdcd", "server" : "WIN--20141018KO", "clientAddr" : "127.0.0.1:50644", "time" : ISODate("2014-11-08T11:01:40.826Z"), "what" : "moveChunk.commit", "ns" : "slidetest.spreadsheets", "details" : { "min" : { "username" : { "$minKey" : 1 }, "_id" : { "$minKey" : 1 } }, "max" : { "username" : "albertshao", "_id" : ObjectId("545df80537216b1577de0251") }, "from" : "shard-a", "to" : "shard-b", "cloned" : NumberLong(0), "clonedBytes" : NumberLong(0), "catchup" : NumberLong(0), "steady" : NumberLong(0) } }mongos>

How can mongodb deploy an extension cluster with keyfile, one route, three configurations, and three shards?

On the node where the slice is configured
Mongod -- port 27017 -- fork -- logpath ar/log/mongo_shard1.log -- dbpath/data0/mongo/shard1 -- shardsvr
Mongod -- port 27018 -- fork -- logpath ar/log/mongo_shard2.log -- dbpath/data0/mongo/shard2 -- shardsvr
Mongod -- port 27217 -- fork -- logpath ar/log/mongo_config.log -- dbpath/data0/mongo/config -- configsvr
Configure routes
Mongos -- port 27417 -- fork -- logpath ar/log/mongos. log -- configdb 127.0.0.1: 27217 -- chunkSize 1
Configure shard on the client
Mongo -- port 27417
MongoDB shell version: 1.6.5
Connecting to: 127.0.0.1: 27417/test
> Use admin;
Switched to db admin
> Db. runCommand ({addshard: "127.0.0.1: 27017 "})
{"ShardAdded": "shard0000", "OK": 1}
> Db. runCommand ({addshard: "127.0.0.1: 27018 "})
{"ShardAdded": "shard0001", "OK": 1}

Next we enable Sharding for DataBase "foo" and set the shard key of Collection "col" to "{_ id: 1}" to test the Sharding function:
> Db. runCommand ({enablesharding: 'foo '});
{"OK": 1}
> Db. runCommand ({shardcollection: "foo. col", key: {_ id: 1 }});
{"Collectionsharded": "foo. col", "OK": 1}

How can I save the mongodb cluster after it is configured? Can it be used after it is started up next time? Windows Environment

It could have been.
In replica set mode, cluster parameters are written inside each node.
For the sharding mode, the Cluster Parameters are written in the configuration server.