[DOCS-12429] Incorrect description of behavior of fsyncLock with WT Created: 06/Feb/19 Updated: 30/Oct/23 Resolved: 11/Feb/19 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Ravind Kumar (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 5 years, 2 days ago | ||||||||
| Epic Link: | DOCSP-1769 | ||||||||
| Description |
DescriptionIn our description of fsyncLock we say that fsyncLock ensures "that the data files do not change", but I don't believe this is true: it only ensures that they don't change in a way that will corrupt a copy taken while the instance is fsyncLock'ed. Scope of changesImpact to Other Docs
MVP (Work and Date)Resources (Scope or Design Docs, Invision, etc.) |
| Comments |
| Comment by Githook User [ 11/Feb/19 ] |
|
Author: {'name': 'rkumar-mongo', 'email': 'ravind.kumar@mongodb.com'}Message: |
| Comment by Ravind Kumar (Inactive) [ 11/Feb/19 ] |
|
Changes published to master/v4.0 -> v3.2. |
| Comment by Githook User [ 11/Feb/19 ] |
|
Author: {'name': 'rkumar-mongo', 'email': 'ravind.kumar@mongodb.com'}Message: |
| Comment by Githook User [ 11/Feb/19 ] |
|
Author: {'name': 'rkumar-mongo', 'email': 'ravind.kumar@mongodb.com'}Message: |
| Comment by Githook User [ 11/Feb/19 ] |
|
Author: {'name': 'rkumar-mongo', 'email': 'ravind.kumar@mongodb.com'}Message: |
| Comment by Githook User [ 11/Feb/19 ] |
|
Author: {'name': 'rkumar-mongo', 'email': 'ravind.kumar@mongodb.com'}Message: |
| Comment by Alexander Gorrod [ 07/Feb/19 ] |
That sounds like an accurate description to me. |
| Comment by Bruce Lucas (Inactive) [ 06/Feb/19 ] |
|
OK. From a documentation perspective I think what we need to say is that under WT fsyncLock does not prevent the data files from changing, but it does ensure that it is safe to copy the files even though they may change during the process. The importance of the distinction is illustrated by |
| Comment by Daniel Gottlieb (Inactive) [ 06/Feb/19 ] |
As a clarification, I wouldn't consider these hot backups. The system is up, but it is not accepting any writes. There's a 4.2 (completed) project that allows file system copies while still accepting writes. It uses the same WT backup cursor technique under the hood, just without taking a global X lock. |
| Comment by Daniel Gottlieb (Inactive) [ 06/Feb/19 ] |
|
Yes, we create a backup cursor on WT. That call is what satisfies the second property. |
| Comment by Daniel Gottlieb (Inactive) [ 06/Feb/19 ] |
|
I'd prefer if the documentation stipulated two things:
It's probably best to caveat data down to "what users put into the database" and not internal writes. Examples of internal writes include update to <database>.system.* collections and replication related collections in the local database. I don't think* any of those can be occur while the system is fsyncLocked, but stating so seems like an unnecessary thing to guarantee. |
| Comment by Ravind Kumar (Inactive) [ 06/Feb/19 ] |
|
Can we define or maybe spitball some examples of 'logical changes' that would not occur? That I think might be more useful for users as far as conceptualizing exactly what fsynclock does and does not do. Or does journal flushes + checkpoints more or less cover what fsynclock does allow.
|