The recommended process for doing a sharded cluster version upgrade is:
- Upgrade mongos (with --upgrade)
- Upgrade shards
- Upgrade config servers
However, when running this for a 2.4 to 2.5 version upgrade, the following error is thrown when a client (e.g. a mongo process) attempts to run the authSchemaUpgradeStep command on the admin database.
{ "ok" : 0, "errmsg" : "SyncClusterConnection::update prepare failed: localhost.mongodb.com:29001:10276 DBClientBase::findN: transport error: localhost.mongodb.com:29001 ns: admin.$cmd query: { resetError: 1 } localhost.mongodb.com:29002:10276 DBClientBase::findN: transport error: localhost.mongodb.com:29002 ns: admin.$cmd query: { resetError: 1 }", "code" : 8005 }
However if the order is changed a bit:
- Upgrade shards
- Upgrade config servers
- Upgrade mongos (with --upgrade)
There are no issues upgrading in this order.
- depends on
-
DOCS-2659 Document v2.6 upgrade order
- Closed
- is duplicated by
-
SERVER-12234 MongoS connections that persist across an upgrade become stale and can cause subsequent operations to fail
- Closed
- is related to
-
SERVER-4887 sharded queries on system.indexes hit the primary
- Closed
- related to
-
DOCS-2682 doc 2.6 upgrade of sharded cluster
- Closed