Mongodb upgrade advice pls

37 views

Skip to first unread message

st...@virtualserve.biz

unread,

Jul 13, 2016, 2:44:09 AM7/13/16

to mongodb-user

Hi,

I am completely new to the world of MongoDB, my company has a MongoDB version 2.2.2 which needs to be upgraded.

In a Test environment I recreated MongoDB 2.2.2 stand alone and then followed the process of upgrading.

we do not use user accounts as this is a isolated server

Stopped and started the service for each upgrade

2.4

2.6 connected a 2.6 mongo shell to your MongoDB 2.4 mongos or mongod and run the db.upgradeCheckAllDBs() to check your data set for compatibility. Passed

3.0

3.2.7 Latest version

I can see all the data and Mongovue shows the correct version have I missed anything?

The reason I ask is how come you cannot just jump from the old version to the new if you are only over writing the .bin files or is it every time I start Mongo the new files make changes to the data?

Steep learning curve but very interesting any recommendation on reading materials would also be very helpful.

Regards

Steve

Stephen Steneker

unread,

Jul 13, 2016, 7:09:36 AM7/13/16

to mongodb-user

On Wednesday, 13 July 2016 16:44:09 UTC+10, steve wrote:

I can see all the data and Mongovue shows the correct version have I missed anything?

The reason I ask is how come you cannot just jump from the old version to the new if you are only over writing the .bin files or is it every time I start Mongo the new files make changes to the data?

Hi Steve,

There are generally metadata or configuration changes in successive major releases (i.e. 2.4 => 2.6, 3.0 => 3.2) that require stepwise upgrades if you want to ensure a smooth upgrade. Many of these changes happen transparently, but skipping major releases can take you into untested territory (particularly if you are using features like authentication, replication, or sharding).

The release notes for each major release go into specific detail on prerequisites, upgrade procedures for different deployment types, and known compatibility or behaviour changes.

If you look closely at the logs when first starting up MongoDB with data files created in an earlier major release, you may notice data files or indexes automatically being upgraded to a newer format. With the MMAP storage engine (which would be the storage engine used if you are upgrading data files from 2.2) you could try checking the internal data file version for a given database before and after the upgrade using db.stats().dataFileVersion. If you try to open upgraded data files with an older release of MongoDB you will likely get a message like “run —upgrade to upgrade dbs, then start again” which means the database files need to be rebuilt for compatibility.

Aside from server upgrades, you also need to consider driver compatibility. Some server changes (eg. SCRAM-SHA-1 default authentication mechanism and storage engine API added in MongoDB 3.0) will require a driver upgrade for support. For example, MongoVUE (as at 1.6.9) has not been updated for MongoDB 3.0+ so you will have significantly less success with this tool if you deploy a new MongoDB 3.2 install (which will use the WiredTiger storage engine and new storage API) or enable authentication (which will use SCRAM-SHA-1).