[SERVER-37484] Only alter table logging settings on startup and not collection creation Created: 05/Oct/18 Updated: 29/Oct/23 Resolved: 15/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.6, 4.1.6 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | Daniel Gottlieb (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||||||||||||||||||
| Sprint: | Storage NYC 2018-11-19 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||
| Description |
|
For upgrade and --enableMajorityReads toggling, startup of a 4.1 mongod must accommodate cases where table logging settings are not in the desired state for the current process lifetime. Currently that modification is done in the WTRecordStore and WTIndex constructors. The constructor code path is hit in 3 cases:
Because the desired setting cannot change during the lifetime of a process, ideally we'd only perform the operation on startup (creating new tables selects the right one). I don't believe there's a clear way to distinguish between these cases; Going by alexander.gorrod's last comment, we can first query the metadata and do a (fragile) string search for log=(enabled=<true|false>) and only call alter if the settings need to be changed. |
| Comments |
| Comment by Githook User [ 15/Jan/19 ] |
|
Author: {'username': 'dgottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb'}Message: (cherry picked from commit 9f2d9ce70ecf475386ead7374bf749e0f231c294) |
| Comment by Githook User [ 15/Nov/18 ] |
|
Author: {'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}Message: |
| Comment by Alexander Gorrod [ 08/Oct/18 ] |
|
daniel.gottlieb it is actually different for WiredTiger. Retrieving metadata is a query via a cursor, so doesn't acquire any strong locks. The WT_SESSION::alter method changes the state of a handle - WiredTiger requires exclusive access to make such changes. We don't have an optimization in place to avoid taking the lock if there is no change, partly because parsing configuration options is moderately expensive/complex in WiredTiger. If MongoDB can do that comparison simply it would likely be a simpler change. |
| Comment by Daniel Gottlieb (Inactive) [ 05/Oct/18 ] |
|
A quick clarification alexander.gorrod. I made an assumption resulting in how I described this ticket. Specifically, I assumed that having MongoDB query and parse the table logging settings from a metadata:create cursor would still acquire the locks that result in the behavior we're trying to correct. If that's not true, would it be a reasonable alternative for adjusting the table logging settings to simply do a "check and set"? |
| Comment by Daniel Gottlieb (Inactive) [ 05/Oct/18 ] |
|
Regarding the dependency on Re-introducing the ability to disable majority reads in 4.1 as part of |