[SERVER-66139] Stuck on oplog visibility when inserting directly into oplog namespace in standalone mode Created: 03/May/22  Updated: 29/Oct/23  Resolved: 16/May/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.0-rc6, 6.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Henrik Edin Assignee: Henrik Edin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
is caused by SERVER-64125 MDB server sets the commit/durable ti... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v6.0
Sprint: Execution Team 2022-05-16, Execution Team 2022-05-30
Participants:

 Description   

Writing directly to the oplog namespace in standalone mode causes any readers of the oplog to be stuck waiting for oplog visibility.

SERVER-64125 changed the insert path to not set a timestamp in this case. That causes WiredTigerOplogManager::triggerOplogVisibilityUpdate not to be called because WiredTigerRecoveryUnit::_isTimestamped is false. Any reader waits forever for oplog visibility that never happens.



 Comments   
Comment by Githook User [ 16/May/22 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-66139 Disable oplog visibility in standalone mode

(cherry picked from commit fbdcf79b38b141aa89d7b38ddcf40d4065c4c2ae)
Branch: v6.0
https://github.com/mongodb/mongo/commit/04e49a5d48ac6e9486f196806efae1ed11d79948

Comment by Githook User [ 16/May/22 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-66139 Disable oplog visibility in standalone mode
Branch: master
https://github.com/mongodb/mongo/commit/fbdcf79b38b141aa89d7b38ddcf40d4065c4c2ae

Comment by Eric Milkie [ 04/May/22 ]

I think that fix should be fine. I'm surprised that the oplog namespace in standalone mode isn't already behaving like a regular capped collection; I think it used work that way for mmapV1 at least.

Comment by Henrik Edin [ 04/May/22 ]

My proposed fix will make a Collection on the oplog namespace behave like a regular (capped) Collection in standalone mode. No special visibility and users can read everything. That is what we need I think. Just unsure about your comment milkie@mongodb.com, such behavior should be ok for shared restore and we don't need a new procedure?

Generated at Thu Feb 08 06:04:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.