[SERVER-52617] Cache the pointer to the oplog collection before running recoverToOplogTimestamp Created: 04/Nov/20 Updated: 29/Oct/23 Resolved: 04/Nov/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.2 |
| Type: | Bug | Priority: | Blocker - P1 |
| Reporter: | Lingzhi Deng | Assignee: | Lingzhi Deng |
| 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 | ||||||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||||||
| Sprint: | Execution Team 2020-11-16 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
For recoverFromOplogAsStandalone, we haveĀ this to set up the oplog collection pointer correctly before running any replication recovery. And this is needed since But we are missing the acquireOplogCollectionForLogging call in recoverFromOplogUpTo. Additionally, the oplog name in LocalOplogInfo is not set up correctly read-only mode with recoverToOplogTimestamp (it only considers the recoverFromOplogAsStandalone case). Last but not least, we dont seem to have any integration test coverages for running the server in readOnly mode with the recoverToOplogTimestamp server parameter. |
| Comments |
| Comment by Githook User [ 04/Nov/20 ] |
|
Author: {'name': 'Lingzhi Deng', 'email': 'lingzhi.deng@mongodb.com', 'username': 'ldennis'}Message: |
| Comment by Lingzhi Deng [ 04/Nov/20 ] |
|
Making this a 4.4 only ticket. And the work for master will be done in |