[SERVER-20406] Replication code misunderstands which storage engine is being used in some circumstances Created: 14/Sep/15 Updated: 25/Jan/17 Resolved: 15/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.2.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Benety Goh |
| 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: | RPL A (10/09/15), Repl B (10/30/15) | ||||||||
| Participants: | |||||||||
| Description |
|
The code used at start up to inform the replication subsystem whether or not the storage engine supports read committed is incorrect. If the user has not specified a storage engine in the config file or at the command line, storageGlobalParams.engine will be set to wiredTiger, but in that scenario the actual storage engine is chosen based on the contents of the --dbpath directory. This scenario is detected by consulting the storageGlobalParams.engineSetByUser predicate, but in this case there is no way to find out the actual type of the storage engine at this point in time. Unfortunately, the current implementation leads to bad behavior when configuring a replica set to act as a config server, because such sets should refuse to admit mmapv1 nodes as members. This problem is related to |
| Comments |
| Comment by Githook User [ 15/Oct/15 ] |
|
Author: {u'username': u'benety', u'name': u'Benety Goh', u'email': u'benety@mongodb.com'}Message: |
| Comment by Eric Milkie [ 15/Sep/15 ] |
|
The condition for determining whether the storage engine supports read committed becomes known after startThreads() is called in the repl coord external state. We could tell the topology coordinator at the same time. |