How to upgrade MongoDB without downtime

Transcription

1 How to upgrade MongoDB without downtime

2 me Adamo Tonete, Senior Technical Engineer Brazil

3 Agenda Versioning Upgrades Operations that always require downtime Upgrading a replica-set Upgrading a sharded cluster Live demo - changing versions Review Q&A 3

4 Versioning

5 Versioning Production-ready releases are even numbers: 2.2, 3.0, 3.2 Never EVER use an odd version in production. 2.3, 3.3 are testing versions. 5

6 Versioning How to read version numbers: = release series 15 = revision 6

7 Upgrading

8 Major and Minor upgrades Minor upgrades are very straight forward, just drop in replacement. What is a minor upgrade? Replacing with is a revision upgrade. Database still in the same versions, some fixes were added and might some new features without breaking backwards compatibility. 8

9 Major and Minor upgrades Minor upgrades may add features from new versions. MongoDB has some features and enhancements that were introduced in Such as config servers as replica-set and improvements on wiredtiger. 9

10 Major and Minor upgrades Major upgrades Moving from 2.6.x to 3.0.x is considered a major upgrade. It usually requires driver updates and some testing. Sometimes there are differences in the database architecture. If a rollback is necessary, it is way more complicated than updating. 10

11 Major and Minor upgrades A few examples: 2.4 to 2.6 new authentication algorithm. 3.0 to 3.2 pluggable storage engine. WiredTiger. 3.2 to 3.4 config servers are now replicasets, data new types, huge changes in WiredTiger, improvements on initial sync. 3.4 to 3.6 pre transactions, sessions. 3.6 to 4.0 transactions. 11

12 Major and Minor upgrades - Rollbacks Sometimes upgrades don't work as we expect, and a version rollback is necessary. It is usually possible to rollback, but please check the documented steps before upgrading. 12

13 Feature Compatibility Version Since version 3.4 it has been possible to turn off new version features to keep compatibility with previous versions. With that option, it is possible to make 3.4 behave like 3.2, and the same is true for

14 Operations that require downtime

15 Operations that require downtime Enable security Change cluster shared key Change listen ip 15

16 Upgrading a replica-set

17 Upgrading a replica-set In order to upgrade a replica-set, we will take advantage of high availability. 17

18 Upgrading a replica-set Removing a secondary or setting the instance as hidden: 18

19 Upgrading a replica-set Then drivers will see this configuration: 19

20 Upgrading a replica-set Repeat the process in the remaining secondaries: 20

21 Upgrading a replica-set Step the primary down and replace the remaining old instance. 21

22 Upgrading a replica-set It is not necessary to remove the old versions while updating. We can set the instance as hidden : true in the rs.config() before removing them. The application driver must be aware of the replica-set configuration, otherwise the application may face downtime. It is preferable to trigger an election (to step down the primary) as the last operation in the upgrade. 22

23 Upgrading a sharded environment

24 Upgrading a sharded environment A sharded cluster is one or more shards (replica-sets) managed by the mongo config servers and mongos processes. In order to upgrade the shards, we can follow exactly the same steps as we've used in the replicasets. However, there is a sequence to be respected when upgrading a sharded cluster. 24

25 Upgrading a sharded cluster 1. Stop the balancer 2. Upgrade the config servers 3. Upgrade the shards 4. Upgrade the mongos 5. Re-enable the balancer 25

26 Live Demo

27 This can be a bit boring... 27

28 Upgrading Replica-set

29 Changing the storage engine on the fly

30 Review

31 Review The driver plays a very important part in keeping the application online. Do not move from an ancient version to a new one. Test the new version before applying it in production. Create backups before upgrading. 31

32 Q&A

33 Rate Our Session 33

34 Thank you!