Welcome to the MongoDB Community Forums @Nand_Sharma !
It sounds like your database version changes are referring to application schema rather than MongoDB server upgrades. If so, I believe the feature you are describing is “schema migration”, which is not handled directly by the MongoDB server (and strictly speaking, not a requirement for all use cases). However, there are quite a few libraries and language-agnostic schema migration tools.
The general pattern for schema migration tools is:
-
Individual schema migrations have an associated script where you write functions for upgrade (and optionally, downgrade) paths. Developers usually find it convenient to write migration scripts using the same language/driver as their application.
-
Each migration script has a unique ID and is typically named with a convention that ensures migrations are run in a predictable order.
-
Migration scripts can be checked into source control and versioned & packaged with your application release. A database instance could be upgraded to 1.2.3 from any prior version by applying all outstanding migration scripts in a predictable order.
-
The migration tool keeps track of migrations that have already been applied to the local database (usually, in the database itself) so migrations are not applied more than once.
No change in schema
You mentioned mongodump/mongorestore, but if there are no schema changes you could take a mongodump backup but wouldn’t need to restore.
A column removed or added:
This could be done via a migration script, but I’d definitely backup before destructive changes.
A difficult situation where let suppose in the Customer collection in 2.0.0 we split the column name into first, middle, and last name or move address to another collection, and the client database is at version 1.0.3.
This sort of data manipulation could be also done via a migration script.
A basic example of this sort of schema migration tool is mongo-migrate for Node.js.
Regards,
Stennie