[SERVER-25623] addShard should fail if shard's binary version < the cluster's featureCompatibilityVersion Created: 15/Aug/16 Updated: 12/Oct/17 Resolved: 02/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2017-10-02, Sharding 2017-10-23 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 0 | ||||||||||||
| Description |
|
In general the upgrade order for a sharded cluster is config servers first, then shards, then mongoses. Thus it is illegal for a mongos from the current version to ever talk to a mongod from the previous version. To enforce this, we need to prevent new mongoses from processing an addShard request that will result in an old mongod being added to the cluster. For the 3.2->3.4 upgrade we handled this in |
| Comments |
| Comment by Githook User [ 03/Oct/17 ] |
|
Author: {'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi', 'username': 'EshaMaharishi'}Message: |
| Comment by Githook User [ 02/Oct/17 ] |
|
Author: {'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi', 'username': 'EshaMaharishi'}Message: move add_invalid_shard.js to jstests/multiVersion since it starts a 'last-stable' mongod |
| Comment by Githook User [ 02/Oct/17 ] |
|
Author: {'email': 'ian.whalen@gmail.com', 'name': 'Ian Whalen', 'username': 'IanWhalen'}Message: Revert " This reverts commit 80b4173ab3ad46eed8f4f482e5fe34bf6546d2e6. |
| Comment by Githook User [ 02/Oct/17 ] |
|
Author: {'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi', 'username': 'EshaMaharishi'}Message: |