How to Scale MongoDB. Apr

Transcription

1 How to Scale MongoDB Apr

2 About me Location: Skopje, Republic of Macedonia Education: MSc, Software Engineering Experience: Lead Database Consultant (since 2016) Database Consultant ( ) Web Developer, DBA ( ) Certifications: C100DBA - MongoDB certified DBA (since 2016)

3 Overview What is HA, how MongoDB achieves HA Replica set, components, deployment topologies Scaling (Vertical vs Horizontal) What is a sharded cluster in MongoDB Cluster components - shards, config servers, mongos Shard keys and chunks Hashed vs range based sharding Sharded cluster backups and upgrades QA

4 HA

5 What is HA? High availability refers to systems that are durable and likely to operate continuously without failure for a long time single point of failure (SPOF) is a part of a system that, if it fails, will stop the entire system from working SPOF? Application SPOF? Database

6 What is HA? HA on the Application vs Database layer Splitting Writes and Read operations Database Load Balancer Application... Application Load Balancer? Writes Reads Primary Replica Replica

7 What is HA? Application node failure Database node failure Failover (elect new Primary node) Database Load Balancer Application... Application Load Balancer? Writes Reads Primary Replica Replica

8 HA with MongoDB - replica sets Group of mongod processes that maintain the same data set Redundancy and high availability Increased read capacity (scaling reads) Automatic failover

9 Replication concept 1. Write operations go to the Primary node 2. All changes are recorded into operations log 3. Asynchronous replication to Secondary 4. Secondaries copy the Primary oplog Secondary can use sync source Secondary

10 Replication concept 1. Write operations go to the Primary node 2. All changes are recorded into operations log 3. Asynchronous replication to Secondary 4. Secondaries copy the Primary oplog 5. Secondary can use sync source Secondary oplog

11 Replication concept 1. Write operations go to the Primary node 2. All changes are recorded into operations log 3. Asynchronous replication to Secondary 4. Secondaries copy the Primary oplog oplog 5. Secondary can use sync source Secondary 3. 3.

12 Replication concept 1. Write operations go to the Primary node 2. All changes are recorded into operations log 3. Asynchronous replication to Secondary 4. Secondaries copy the Primary oplog oplog 5. Secondary can use sync source Secondary

13 Replication concept 1. Write operations go to the Primary node 2. All changes are recorded into operations log 3. Asynchronous replication to Secondary 4. Secondaries copy the Primary oplog oplog 5. Secondary can use sync source Secondary* *settings.chainingallowed (true by default) 5.

14 Configuration options 50 members per replica set (7 voting members) Arbiter node Priority 0 node Hidden node Delayed node

15 Arbiter node Does not hold copy of data Votes in elections Arbiter hidden : true

16 Arbiter node Does not hold copy of data Votes in elections Arbiter hidden : true

17 Priority 0 node Priority - floating point (i.e. decimal) number between 0 and 1000 Cannot become primary, cannot trigger election Visible to application Secondary priority : 0

18 Hidden node Not visible to application Never becomes primary Use cases reporting backups Secondary hidden : true priority : 0 hidden: true priority:0 hidden : true

19 Delayed node Must be priority 0 member Should be hidden member (not mandatory) Mainly used for backups Recovery in case of human error Secondary slavedelay : 3600 priority : 0 hidden : true

20 Scaling

21 Scaling Working set - amount of memory that a process requires in a given time interval Time for scaling?

22 Scaling Vertical scaling Adding more power (CPU, RAM, DISK) to an existing machine Might require downtime while scaling up Horizontal scaling Adding more machines into your pool of resources Partitioning the data on multiple machines Parallelizing the processing More complex to implement and maintain

23 Scaling costs *

24 Scaling with MongoDB

25 Scaling (sharding) with MongoDB Shard Shard Data

26 Sharding with MongoDB Shard/Replica set (subset of the sharded data) Config servers (metadata and config settings) mongos (query router, cluster interface) Shard Data

27 Sharding with MongoDB Shard/Replica set (subset of the sharded data) Config servers (metadata and config settings) mongos (query router, cluster interface) mongos> sh.addshard("shardn") 1 2 N-1 N

28 Shards Contains subset of sharded data Replica set for redundancy and HA Primary shard Non sharded collections --shardsvr in config file (port 27018)

29 Config servers Stores the metadata for sharded cluster in config database Authentication configuration information in admin database Config servers as replica set only (>= 3.4) Holds balancer on Primary node (>= 3.4) --configsvr in config file (port 27019)

30 mongos Caching metadata from config servers Routes queries to shards No persistent state Updates cache on metadata changes Holds balancer (mongodb <= 3.2) mongos version 3.4 cannot connect to earlier mongod version

31 Sharding collection Enable sharding on database users sh.enablesharding("users") Shard collection history sh.shardcollection("users.history", { user_id : 1 } ) Shard key - indexed key that exists in every document in the collection range based sh.shardcollection("users.history", { user_id : 1 } ) hashed based sh.shardcollection( "users.history", { user_id : "hashed" } )

32 Ranged sharding Dividing data into contiguous ranges determined by the shard key values Documents with close shard key values are likely to be in the same chunk or shard Query Isolation - more likely to target single shard for range queries

33 Hashed sharding Uses a hashed index of a single field as the shard key to partition data More even data distribution at the cost of reducing Query Isolation Applications do not need to compute hashes Keys that change monotonically like ObjectId or timestamps are ideal

34 Shard keys and chunks Choosing Shard key Large Shard Key Cardinality Low Shard Key Frequency Non-Monotonically changing shard keys Chunks A contiguous range of shard key values within a particular shard Inclusive lower and exclusive upper range based on shard key Default size of 64MB ([ ] MB)

35 Shard keys limitations Must be ascending indexed key or indexed compound keys that exists in every document in the collection Cannot be multikey index, a text index or a geospatial index Cannot exceed 512 bytes Immutable key - can not be updated/changed Update operations that affect a single document must include the shard key or the _id field No option for sharding if unique indexes on other fields exist No option for second unique index if the shard key is unique index

36 Sharded clusters backup Filesystem snapshot Stop the balancer Lock one Secondary member of each replica set and config server Take snapshot for each replica set and config server Unlock the Secondaries and start the balancer Database dump (mongodump) Run mongodump while connected to mongos (takes long for larger datasets) Percona mongodb_consitent_backup tool MongoRocks - rocksdbbackup tool Cloud manager backup (requires monthly fee)

37 Sharded clusters upgrade Upgrading a cluster with MongoDB 3.0 to MongoDB 3.6 requires upgrade path of all major versions including 3.0 -> 3.2 -> 3.4 -> 3.6 Taking backup of the config servers (metadata) is highly recommended Driver compatibility check and driver upgrade as first step Steps for Sharded Cluster upgrade include Stop the balancer Upgrade config servers Upgrade shards Upgrade mongos Start the balancer

38 Summary Replica set with odd number of voting members Hidden or Delayed member for dedicated functions (reporting, backups ) Dataset fits into single server, keep unsharded deployment Horizontal scaling - shards running as replica sets Shard keys are immutable with max size of 512 bytes Shard keys must exists in every document in the collection Ranged sharding may not distribute the data evenly Hashed sharding distributes the data randomly Sharding adds complexity for maintenance (backups and upgrades)

39 Questions?

40 We re Hiring!

41 Rate my session