The changes that MongoDB is bringing to the world in 4.0 are tempting to many companies and administrators, but if you are on an older version such as 3.2, upgrading with minimum disruption can be challenging.
Some of the problems that a company might face are that older language drivers versions may not be compatible with newer versions of mongo, the upgrade path might change, and there is a lot of documentation to read before you embark on the upgrade path.
If in 3.2 the config servers could be both mirrored or replica sets, in 3.4, it's a must to have the config servers as replica sets. Upgrading without interruption can be difficult. With so many things to read about, it's always good to have a reference that will give you an understanding of things that you should consider. A form of cheat sheet.
In this 50 minutes session, I would like to present the steps needed to move from 3.2 to 3.4, which will include some tips to upgrade the config servers to replica sets with minimal disruption and from 3.4 to 3.6 and from 3.6 to 4.0, again, with minimal disruption.
The session will also mention best practices that will apply when running any version upgrade.
Seasoned Linux, Windows and Network administrator, recently turned DBA. After 3 years in the Data Engineering team in ObjectRocket, moved to the DBA team to focus on MongoDB and ElasticSearch.
All round geek with a genuine passion for anything that runs on or involves computers. From the OS to games