[SERVER-29690] MongoS initiated metadata refreshes not based on StaleConfig error may see stale config data Created: 16/Jun/17 Updated: 30/Oct/23 Resolved: 19/Jun/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.2.14, 3.4.5, 3.5.8 |
| Fix Version/s: | 3.5.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Kaloian Manassiev |
| Resolution: | Fixed | 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 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 0 | ||||||||
| Description |
|
MongoS write commands may trigger metadata refresh based on errors other than StaleConfig. In particular, this is what's happening in the coll_epoch_test1.js test. If a collection gets unsharded on one mongos and a write is scheduled against a different mongos, the second mongos will use a stale config server optime. Because of this, if that read hits a stale config server secondary, it won't see the change in the sharding state. This is an inherent problem, which can only be solved through the support in the causal consistency project, so this ticket is filed just as a placeholder for versions prior to 3.6. |
| Comments |
| Comment by Githook User [ 19/Jun/17 ] |
|
Author: {u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}Message: Also makes ShardingTest/ReplSetTest support requesting the creation of |