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-