How to upgrade MongoDB without downtime

me - @adamotonete

Adamo Tonete, Senior Technical EngineerBrazil

3

Agenda

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

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.

6

Versioning

How to read version numbers:

3.2.15

3.2 = release series

15 = revision

Upgrading

8

Major and Minor upgrades

Minor upgrades are very straight forward, just drop in replacement.

What is a minor upgrade?

Replacing 3.2.14 with 3.2.15 is a revision upgrade.

Database still in the same versions, some fixes were added and might some new features without breaking backwards compatibility.

9

Major and Minor upgrades

Minor upgrades may add features from new versions.

MongoDB 3.2.10 has some features and enhancements that were introduced in 3.4...

Such as config servers as replica-set and improvements on wiredTiger.

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.

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.

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.

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 3.6

Operations that require downtime

15

Operations that require downtime

● Enable security● Change cluster shared key● Change listen ip

Upgrading a replica-set

17

Upgrading a replica-set

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

18

Upgrading a replica-set

Removing a secondary or setting the instance as hidden:

19

Upgrading a replica-set

Then drivers will see this configuration:

20

Upgrading a replica-set

Repeat the process in the remaining secondaries:

21

Upgrading a replica-set

Step the primary down and replace the remaining old instance.

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.

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.

25

Upgrading a sharded cluster

1. Stop the balancer2. Upgrade the config servers3. Upgrade the shards4. Upgrade the mongos5. Re-enable the balancer

Live Demo

27

This can be a bit boring...

Upgrading Replica-set

Changing the storage engine on the fly

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.

Q&A

33

Rate Our Session

Thank you!