The document discusses 5 key things to know about administering MongoDB: 1) Understanding MongoDB's architecture and memory usage, 2) Protecting data through replication and deployment strategies, 3) Scaling writes and reads using sharding, 4) Monitoring MongoDB performance using tools like MMS, and 5) Backing up and restoring data with tools like mongodump/mongorestore. It provides examples and explanations of useful commands for tasks like replication, sharding, and monitoring MongoDB deployments.

1. #MongoDBDays
5 Things you need to know
about Administering MongoDB
Alvin Richards
Senior Director of Performance Engineering, MongoDB

2. #MongoDBDays
Or…
A Dev and Ops "Love Story"
Alvin Richards
Senior Director of Performance Engineering, MongoDB

3. Before we start…
• I'm assuming you have at least
– installed MongoDB
– Have done some basic Admin
• I'm not assuming you have
– Been running in production for any length of time

4. Dev are from Mars and Ops are from
Venus…
DEV OPS

5. 5 Things you need to know
1. Know Thy Beast
2. Protecting data
3. Scaling Writes & Reads
4. Monitoring
5. Backing up & Restoring

6. #1
Know thy beast

7. Architecture
• Shipped as Binaries
• tarball, zip file
• Packages(rpm, yum)
• MSI (for Windows)
• Runs a background process mongod (or
mogod.exe)
• Uses Memory Mapped Files

8. Memory Mapped files – dude whoa
• To MongoDBmemory is an infinite-ish pool
• 64 TB Linux / Windows 2012 R2 / Windows 8.1
• 4 TB earlier Windows versions
• MongoDB accesses memory locations in virtual
memory
• O/S may have to page in that data from storage
• O/S may have to page out data from RAM
• Physical RAM acts as a LRU cache

9. Collection
1
Index 1

10. Virtual
Address
Space 1
Collection
1
Index 1
This is your virtual
memory size (mapped)

11. Physical
RAM
Collection
1
Index 1
This is your
resident memory
size
Virtual
Address
Space 1

12. Collection Disk
1
Physical
RAM
Index 1
Virtual
Address
Space 1

13. Collection Disk
1
Physical
RAM
Index 1
100 ns
10,000,000 ns
=
=
Virtual
Address
Space 1

14. What Memory is used for
• Working Set
– Active Data & Indexes in Memory
• Sorting
• Aggregation & Map/Reduce
• Connections

15. Working Set Exceeds Physical
Memory

16. Where can I find this info?
> db.serverStatus( { workingSet: 1 } )
…
"workingSet" : {
"note" : "thisIsAnEstimate",
"pagesInMemory" : 378,
"computationTimeMicros" : 4104,
"overSeconds" : 4646
},

17. Where can I find this info?
> mongostat
…
Insert query update delete getmore command flushes mapped vsize res
*0 *0 *0 *0 0 1|0 0 160m 2.75g 5m
*0 *0 *0 *0 0 1|0 0 160m 2.75g 5m
> iostat
> sar
> vmstat
Windows: Perfmon

18. #2
Protecting data

19. Deployment - Single Node
Good
• Write ahead journaling for
crash protection
Bad
• Cannot survive loss of
one node
Primary – A

20. Oppps
http://i.ytimg.com/vi/PzWK9QCYgH8/hqdefault.jpg

21. Replica Set – Initialize

22. Replica Set – Failure

23. Replica Set – Failover

24. Replica Set – Recovery

25. Replica Set – Recovered

26. Oops… Multiple Failures
http://f1-grandprix.com/wp-content/uploads/wppa/565.jpg

27. Deployment–Single Data Center
Good
• Automated failover
• Tolerates server failures
• Tolerates rack failures
• Number of replicas
defines failure tolerance
Bad
• Cannot survive loss of
Data Center
Primary – A
Secondary – B
Secondary – C

28. Deployment - Active/Active Data
Center
US-B
Data Center - US
US-A
EU-C
EC-D
ASIA-E
Data Center - Europe Data Center - Asia
Good
• Tolerates server, rack, data center failures, network
partitions
Bad
• Complexity but "MMS Automation to the rescue" ™

29. Useful commands
> rs.status()
{
"set" : "foo",
"date" : ISODate("2014-09-08T01:29:58Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "vero.local:31000",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 28,

30. Useful commands
> rs.printReplicationInfo()
configured oplog size: 192MB
log length start to end: 0secs (0hrs)
oplog first event time: Sun Sep 07 2014 18:17:52 GMT-0700 (PDT)
oplog last event time: Sun Sep 07 2014 18:29:52 GMT-0700 (PDT)
now: Sun Sep 07 2014 18:30:49 GMT-0700 (PDT)

31. Application Considerations
Dev Ops

32. Tunable Data Durability
Memory Journal Secondar
y
Other Data Center
RDBMS
w=1
j=true
w="majority
"
w=n
w="myTag
"
Latenc
y
async
sync
Durability

33. #3
Scaling Writes & Reads

34. #3.1
Scaling Writes

35. Sharding - Range distribution
sh.shardCollection("test.tweets", {user: 1} , false)
shard01 shard02 shard03

36. Sharding - Range distribution
shard01 shard02 shard03
a-i j-r s-z

37. Shard Key Options
• Single or Compound Key
• Regular or Hashed key
• Tagged

38. Sharding – Auto Splits
shard01 shard02 shard03
a-i ja-jz s-z
k-r

39. Sharding – Auto Splits
shard01 shard02 shard03
a-i ja-ji s-z
ji-js
js-jw
jz-r

40. Sharding - Auto Balancing
shard01 shard02 shard03
a-i ja-ji s-z
ji-js
js-jw
jz-r
js-jw
jz-r

41. Sharding - Goal Equilibrium
shard01 shard02 shard03
a-i ja-ji s-z
ji-js
js-jw
jz-r

42. Sharding - Find by Shard Key
find({user: "alvin"})
shard01 shard02 shard03
a-i ja-ji s-z
ji-js
js-jw
jz-r

43. Sharding - Find by Attribute
find({email: "alvin@10gen.com"})
shard01 shard02 shard03
a-i ja-ji s-z
ji-js
js-jw
jz-r

44. Application Considerations
Dev Ops

45. Shard Key
• What key to use?
• Plain or Hashed?
• What's the distribution & usage?
• Predicate & Sorts
– Use the Shard key?
– Scatter Gather + Sort?

46. Useful commands
> sh.status()
...
shards:
{ "_id" : "shard0000", "host" : "localhost:29001", "tags" : [
"dc-emea" ] }
{ "_id" : "shard0001", "host" : "localhost:29002", "tags" : [
"dc-asia" ] }
{ "_id" : "shard0002", "host" : "localhost:29003", "tags" : [
"dc-na" ] }
databases:
{ "_id" : "scaleout", "partitioned" : true, "primary" :
"shard0000" }
scaleout.blogs
shard key: { "loc" : 1 }
chunks: shard0000 1
{ "loc" : { "$minKey" : 1 } } -->>
{ "loc" : { "$maxKey" : 1 } } on : shard0000 Timestamp(1,
0)

47. Useful commands
// Commands to start/Stop the balancer
> sh.startBalancer()
> sh.stopBalancer()
// Disable balancing for a specific collection
> sh.disableBalancing("students.grades")
// Runt the balancer during a specific time window
> db.settings.update({ _id : "balancer" },
{ $set : { activeWindow : { start : "<start-time>",
stop : "<stop-time>" } } }, true )

48. #3.2
Scaling Reads

49. Immediate vs. Eventual
Consistency
• Do you want to read your own writes?
– Use Sharding to Scale Reads
• Are you tolerant to read older versions of data?
– May read from Secondary's

50. Application Considerations
Dev Ops

51. Immediate Consistency
Thread #1 Primary
Insert
Read
Update
Read
v1
✔
v2
✔

52. Eventual Consistency
Thread #1 Primary Secondary
Insert
Read
v1
Thread #2
✖
v1
v1 does not
exist
reads v1
Update
Read
v2
✖
v2

53. Eventual Consistency with a Write
Concern
Thread #1 Primary Secondary
Insert (w=2)
Read
v1
Thread #2
✖
v1 does not
exist
v1 reads v1
✔

54. #4
Monitoring

55. Pick your tool dejour
• Plugins for
– Cacti, Zabix, Munin, NewRelic….
• MongoDB Monitoring (MMS)
– mms.mongodb.com
– Focused on MongoDB cluster well being

56. MMS

57. KPIs you care about
• MongoDB
– MongoDB ops/sec
– Read/Write queues
– Index Misses
– Locked %
– Flush times
– Replication Lag

58. KPIs you care about
• Storage
– IOPS
– Size
– Data & Loading Patterns
• Memory
– Working Set
• CPU
– Speed
– Cores
• Network
– Latency
– Throughput

59. Example
MongoDB
ops/sec
Page Faults /
Sec

60. #5
Backup & Restore

61. Options
• mongodump / mongorestore
• File system snaphot / rsync
• MMS Backup
– Automated Cluster Backup / Restore
– Snapshots
– Point in Time recovery
– OpLog based

62. MMS Backup & Restore

63. Other talks today
• 10.25 – Running MongoDB with confidence with
MMS
• 12.45 –MongoDB Sharding
• 1.05 – Securing Your MongoDB Deployment
• 4.10 – Diagnostics and Debugging

64. Get MongoDB Certified
• 20% off our October exam with the code
• MongoDBSeattle20
• TODAY ONLY
• university.mongodb.com

65. A happy ever after?
Dev Ops

66. #MongoDBDays
Thank You
Alvin Richards
alvin@mongodb.com / @jonnyeight
Senior Director of Performance Engineering, MongoDB