Downgrade MongoDB from 2.6

On this page

Before you attempt any downgrade, familiarize yourself with the content of this document, particularly the Downgrade Recommendations and Checklist and the procedure for downgrading sharded clusters.

Downgrade Recommendations and Checklist

When downgrading, consider the following:

Downgrade Path

Once upgraded to MongoDB 2.6, you cannot downgrade to any version earlier than MongoDB 2.4. If you created text or 2dsphere indexes while running 2.6, you can only downgrade to MongoDB 2.4.10 or later.

Preparedness

Procedures

Follow the downgrade procedures:

Downgrade 2.6 User Authorization Model

If you have upgraded to the 2.6 user authorization model, you must first downgrade the user authorization model to 2.4 before before downgrading MongoDB 2.6 to 2.4.

Considerations

  • For a replica set, it is only necessary to run the downgrade process on the primary as the changes will automatically replicate to the secondaries.
  • For sharded clusters, although the procedure lists the downgrade of the cluster’s authorization data first, you may downgrade the authorization data of the cluster or shards first.
  • You must have the admin.system.backup_users and admin.system.new_users collections created during the upgrade process.
  • Important. The downgrade process returns the user data to its state prior to upgrading to 2.6 authorization model. Any changes made to the user/role data using the 2.6 users model will be lost.

Access Control Prerequisites

To downgrade the authorization model, you must connect as a user with the following privileges:

copy 
{ resource: { db: "admin", collection: "system.new_users" }, actions: [ "find", "insert", "update" ] }
{ resource: { db: "admin", collection: "system.backup_users" }, actions: [  "find" ] }
{ resource: { db: "admin", collection: "system.users" }, actions: [ "find", "remove", "insert"] }
{ resource: { db: "admin", collection: "system.version" }, actions: [ "find", "update" ] }

If no user exists with the appropriate privileges, create an authorization model downgrade user:

1

Connect as user with privileges to manage users and roles.

Connect and authenticate as a user with userAdminAnyDatabase.

2

Create a role with required privileges.

Using the db.createRole method, create a role with the required privileges.

copy 
use admin
db.createRole(
  {
    role: "downgradeAuthRole",
    privileges: [
      { resource: { db: "admin", collection: "system.new_users" }, actions: [ "find", "insert", "update" ] },
      { resource: { db: "admin", collection: "system.backup_users" }, actions: [  "find" ] },
      { resource: { db: "admin", collection: "system.users" }, actions: [ "find", "remove", "insert"] },
      { resource: { db: "admin", collection: "system.version" }, actions: [ "find", "update" ] }
    ],
    roles: [ ]
  }
)
3

Create a user with the new role.

Create a user and assign the user the downgradeRole.

copy 
use admin
db.createUser(
   {
     user: "downgradeAuthUser",
     pwd: "somePass123",
     roles: [ { role: "downgradeAuthRole", db: "admin" } ]
   }
)

Note

Instead of creating a new user, you can also grant the role to an existing user. See db.grantRolesToUser() method.

4

Authenticate as the new user.

Authenticate as the newly created user.

copy 
use admin
db.auth( "downgradeAuthUser", "somePass123" )

The method returns 1 upon successful authentication.

Procedure

The following downgrade procedure requires <database>.system.users collections used in version 2.4. to be intact for non-admin databases.

1

Connect and authenticate to MongoDB instance.

Connect and authenticate to the mongod instance for a single deployment or a mongos for a sharded cluster with the appropriate privileges. See Access Control Prerequisites for details.

2

Create backup of 2.6 admin.system.users collection.

Copy all documents in the admin.system.users collection to the admin.system.new_users collection:

copy 
db.getSiblingDB("admin").system.users.find().forEach( function(userDoc) {
    status = db.getSiblingDB("admin").system.new_users.save( userDoc );
    if (status.hasWriteError()) {
        print(status.writeError);
    }
  }
);
3

Update the version document for the authSchema.

copy 
db.getSiblingDB("admin").system.version.update(
   { _id: "authSchema" },
   { $set: { currentVersion: 2 } }
);

The method returns a WriteResult object with the status of the operation. Upon successful update, the WriteResult object should have "nModified" equal to 1.

4

Remove existing documents from the admin.system.users collection.

copy 
db.getSiblingDB("admin").system.users.remove( {} )

The method returns a WriteResult object with the number of documents removed in the "nRemoved" field.

5

Copy documents from the admin.system.backup_users collection.

Copy all documents from the admin.system.backup_users, created during the 2.6 upgrade, to admin.system.users.

copy 
db.getSiblingDB("admin").system.backup_users
首页