[SERVER-20889] Introduce means to disable sharding minOpTime recovery Created: 12/Oct/15 Updated: 03/Apr/19 Resolved: 22/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.2.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Spencer Brody (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 | ||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||
| Sprint: | Sharding B (10/30/15) | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Description |
|
With the introduction of Config Servers as Replica Sets, shard hosts will checkpoint the latest config server opTime after each metadata operation they perform and if necessary on startup will contact the config server's primary in order to recover the minOpTime that they should be using. This poses problems with restoring a host, which was previously backed up with this recovery information, because it will attempt to connect a potentially defunct config server. For this reason, we need to either have a separate argument, which allows the recovery information to be ignored or we should start requiring --shardSvr to be specified for all shard servers. |
| Comments |
| Comment by Andy Schwerin [ 20/Nov/15 ] |
|
Most important documentation change is to update the restore procedures for sharded clusters and single shards, which is |
| Comment by Spencer Brody (Inactive) [ 22/Oct/15 ] |
|
Sharding state recovery can be disabled by starting mongod with --setParameter=recoverShardingState=false |
| Comment by Githook User [ 22/Oct/15 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: |
| Comment by Cailin Nelson [ 14/Oct/15 ] |
|
Ah, understood. Thanks. |
| Comment by Kaloian Manassiev [ 14/Oct/15 ] |
|
If the minOpTime recovery information is not present, this means that this particular shard never executed any metadata changing operation (i.e., move chunk). Don't think of it as cache, but instead as a progress checkpoint. So this information must be backed up if the node will ever be used as a shard again and patched up on restore to point to the correct config server. |