4.1: Pre-splitting data
mkdir c1 s1 s2 s3
mongod --configsvr --dbpath c1
mongos --configdb m202-ubuntu1404
mongod --dbpath s1 --port 27001
mongod --dbpath s2 --port 27002
mongod --dbpath s3 --port 27003
//sh.addShard( "m202-ubuntu1404:27001" )
db.adminCommand({addShard:"m202-ubuntu1404:27001",name:"shard0"})
db.adminCommand({addShard:"m202-ubuntu1404:27002",name:"shard1"})
db.adminCommand({addShard:"m202-ubuntu1404:27003",name:"shard2"})
sh.stopBalancer()
sh.getBalancerState()
sh.enableSharding("m202")
sh.shardCollection("m202.presplit", {a:1})
db.adminCommand({split : "m202.presplit", middle : { a : 0 }})
db.adminCommand({split : "m202.presplit", middle : { a : 7 }})
db.adminCommand({split : "m202.presplit", middle : { a : 10 }})
db.adminCommand({split : "m202.presplit", middle : { a : 14 }})
db.adminCommand({split : "m202.presplit", middle : { a : 15 }})
db.adminCommand({split : "m202.presplit", middle : { a : 20 }})
db.adminCommand({split : "m202.presplit", middle : { a : 21 }})
db.adminCommand({split : "m202.presplit", middle : { a : 22 }})
db.adminCommand({split : "m202.presplit", middle : { a : 23 }})
db.adminCommand({split : "m202.presplit", middle : { a : 24 }})
sh.moveChunk("m202.presplit", {"a": 14}, "shard1")
sh.moveChunk("m202.presplit", {"a": 15}, "shard1")
sh.moveChunk("m202.presplit", {"a": 20}, "shard1")
sh.moveChunk("m202.presplit", {"a": 21}, "shard2")
sh.moveChunk("m202.presplit", {"a": 22}, "shard2")
sh.moveChunk("m202.presplit", {"a": 23}, "shard2")
sh.startBalancer()
sh.getBalancerState()
4.2: Advantages of pre-splitting
Which of the following are advantages of pre-splitting the data that is being loaded into a sharded cluster, rather than throwing all of the data in and waiting for it to migrate?
- Data can get lost during chunk migration. Pre-splitting allows you to avoid that.
- You have more control over the shard key if you pre-split.
- (OK) You can decide which shard has which data range initially if you pre-split the data
- (OK) Migration takes time, especially when the system is under load. Pre-splitting allows you to avoid that.
4.3: Upgrading a sharded cluster to 3.0
Which of the following are required or recommended when upgrading a sharded cluster to MongoDB 3.0? Check all that apply.
- (OK) If your MongoDB deployment is not already running MongoDB 2.6, upgrade to 2.6 first.
- (OK) Upgrade all mongos instances before upgrading mongod instances.
- Upgrade all mongod instances before upgrading mongos instances.
- (OK) Disable the balancer.
- Upgrade the secondaries on all shards before upgrading any primary.
4.4: Using shard tags to manage data
mongo --nodb
config = { d0 : { smallfiles : "", noprealloc : "", nopreallocj : ""}, d1 : { smallfiles : "", noprealloc : "", nopreallocj : "" }, d2 : { smallfiles : "", noprealloc : "", nopreallocj : ""}};
cluster = new ShardingTest( { shards : config } );
sh.stopBalancer()
sh.addTagRange('testDB.testColl', {createdDate:ISODate("2013-10-01")}, {createdDate:ISODate("2014-02-01")}, "LTS")
sh.addTagRange('testDB.testColl', {createdDate:ISODate("2014-02-01")}, {createdDate:ISODate("2015-01-01")}, "STS")
sh.status()
use config
db.tags.remove({_id : { ns:"testDB.testColl", min:{createdDate:ISODate("2014-01-01")}}, tag:"STS" })
db.tags.remove({_id : { ns:"testDB.testColl", min:{createdDate:ISODate("2013-10-01")}}, tag:"LTS" })
sh.startBalancer()
sh.status()
-eof-