MongoDB Administration 101(Ops Jumpstart)

Marc Schwering

Senior Solutions Architect

MongoDB

@m4rcsch #MonogDBDays

marc@mongodb.com

2

• Overview

• High Availability through Replica Sets

• Scalability through Sharding

• Deployment Architectures

• Database Management

Agenda

Overview

4

MongoDB

Document

Database

General

Purpose

Agile

Scalable

5

• Document Data Model

– App and DB data structures in harmony

– Fast to develop against – quicker to market

• Dynamic Schema

– Polymorphic data is the norm

– Data model can evolve as app evolves – quicker to iterate

• Built-in Horizontal Scalability

– Low infrastructure costs – commodity hosts & no need for SAN

– Elasticity - start small and invest incrementally

Why MongoDB?

Initial DB decision

doesn’t constrain a

successfully growing

business, later on

6

Operational Database

7

Document Data Model

Relational - Tables Document - Collections

{ firstname: ‘Paul’,

surname: ‘Miller’,

city: ‘London’,

location: {

type: “Point”, coordinates :

[-0.128, 51.507]

},

cars: [

{ model: ‘Bentley’,

year: 1973,

value: 100000, … },

{ model: ‘Rolls Royce’,

year: 1965,

value: 330000, … }

]

}

8

Document Data Model

Relational MongoDB

9

Full featured Interaction

Queries • Find Paul’s cars

Geospatial• Find all of the car owners within 5km

of Trafalgar Square

Text Search• Find all the cars with ‘leather seats’ in

their description

Aggregation

& Map Reduce

• Calculate the average value of every

owner’s car collection, and show only

the top 10

{ firstname: ‘Paul’,

surname: ‘Miller’,

city: ‘London’,

location: {

type: “Point”, coordinates :

[-0.128, 51.507]

},

cars: [

{ model: ‘Bentley’,

year: 1973,

value: 100000, … },

{ model: ‘Rolls Royce’,

year: 1965,

value: 330000, … }

]

}

High Availability through

Replica Sets

11

Replica Sets

• Replica Set – two or more copies

• Automated Replication & Failover

• Addresses availability

– High Availability

– Disaster Recovery

– Maintenance (rolling updates)

• Deployment Flexibility

– Data locality to users

– Delayed replicas

– Workload isolation

Primary

Driver

Application

Secondary

Secondary

Replication

12

Replica Set - Initialised

13

Replica Set – Failure & Re-election

14

Replica Set – Failed-over

15

Replica Set - Recovery

16

Replica Set - Recovered

Scalability through

Sharding

18

Needing to Scale-out?

• Increasing volume of persisted data is too

large for host machine?

• Write throughput being constrained by hard

disks of host machine?

• Read latencies being constrained by the

size of memory of host machine?

19

Working Set Exceeding RAM

20

Sharding

Auto-Sharding

• Increase and decrease capacity as you go

• Automatic Balancing

• Transparent to applications

• Scale capacity, scale reads, scale writes

21

Sharding

Deployment Architectures

23

Single Data Centre

• Automated failover

• Tolerates server failures

• Tolerates rack failures

• Number of replicas

defines failure tolerance

Primary – A Primary – B Primary – C

Secondary – A Secondary – ASecondary – B

Secondary – BSecondary – CSecondary – C

24

Active/Standby Data Centres

• Tolerates server and rack failure

• Standby data center for disaster recovery

Data Center - West

Primary – A Primary – B Primary – C

Secondary – ASecondary – B Secondary – C

Data Center - East

Secondary – A Secondary – B Secondary – C

25

Active/Active Data Centres

• Tolerates server, rack, data center failures, network

partitions

Data Center - West

Primary – A Primary – B Primary – C

Secondary – A Secondary – BSecondary – C

Data Center - East

Secondary – A Secondary – B Secondary – C

Secondary – B Secondary – C Secondary – A

Data Center - Central

Arbiter – A Arbiter – B Arbiter – C

26

Global Data Distribution

Real-Time

Real-Time Real-Time

Real-Time

Real-Time

Real-Time

Real-Time

Primary

Secondary

Secondary

Secondary

Secondary

Secondary

Secondary

Secondary

27

Write locally, Read globally

Primary:NYC

Secondary:NYC

Primary:LON

Primary:SYD

Secondary:LON

Secondary:NYC

Secondary:SYD

Secondary:LON

Secondary:SYD

Database Management

29

MongoDB Management Service (MMS)Managed MongoDB on the Infrastructure of Your Choice

30

• Cloud based MMS

or

• On-Prem MMS

• Monitoring

• Backup & Restore

• Automation

– Deployment & Elasticity

– Rolling upgrade/downgrade without downtime

MMS

31

• Continuous low-overhead backup

• Consistent across Shards on different hosts

• Point-in-time recovery

MMS Backup

32

Business Needs Security Features

Authentication

In-database

LDAP

Kerberos

x.509 Certificates

Authorization

Built-in Roles

User-Defined Roles

Field-Level Redaction

AuditingAdmin Operations

Queries (via Partner Solutions)

EncryptionNetwork: SSL (with FIPS 140-2)

Disk: Partner Solutions

Enterprise-Grade Security

33

help

db.help()

db.stats()

> mongostat

> iostat

Windows: perfmon

Console!

34

> db.serverStatus( { workingSet: 1 } )

…

"workingSet" : {

"note" : "thisIsAnEstimate",

"pagesInMemory" : 378,

"computationTimeMicros" : 4104,

"overSeconds" : 4646

},

stats

35

> 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

stats

Questions?@m4rcsch - marc@mongodb.com

37

For More Information

Resource Location

MongoDB Downloads mongodb.com/download

Free Online Training education.mongodb.com

Webinars and Events mongodb.com/events

White Papers mongodb.com/white-papers

Case Studies mongodb.com/customers

Presentations mongodb.com/presentations

Documentation docs.mongodb.org

Resource Location

@m4rcsch - marc@mongodb.com