M202: MongoDB Advanced Deployment and Operations - Chapter 4: Sharded Cluster Management

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-