[SERVER-44349] Log the truncateAfterPoint during startup recovery before clearing it Created: 31/Oct/19  Updated: 29/Oct/23  Resolved: 14/Jul/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Improvement Priority: Major - P3
Reporter: Samyukta Lanka Assignee: William Schultz (Inactive)
Resolution: Fixed Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4
Sprint: Repl 2020-07-27
Participants:

 Description   

During startup recovery, we log the truncateAfterPoint before recovering from the stable timestamp. But before calling _recoverFromStableTimstamp, we clear the truncateAfterPoint, so we aren't logging anything useful.



 Comments   
Comment by Githook User [ 14/Jul/20 ]

Author:

{'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}

Message: SERVER-44349 Clean up some logging in replication recovery
Branch: master
https://github.com/mongodb/mongo/commit/351b9a8d37dde2a79510c784421e29540cac007a

Comment by Dianna Hohensee (Inactive) [ 28/Feb/20 ]

So the code linked in the description indicates that we clear the oplogTruncateAfterPoint in _truncateOplogIfNeededAndThenClearOplogTruncateAfterPoint without logging it, before _recoverFromStableTimestamp gets called afterwards. However, we log the oplogTruncateAfterPoint inside of _truncateOplogIfNeededAndThenClearOplogTruncateAfterPoint.

I think either: _recoverFromStableTimestamp should stop logging the truncate point that will always be cleared by that point; or the truncate point should be saved to a local variable before _truncateOplogIfNeededAndThenClearOplogTruncateAfterPoint is called and then passed into _recoverFromStableTimestamp for logging.

Comment by Dianna Hohensee (Inactive) [ 04/Nov/19 ]

Thanks for the heads up!

I do not believe it will arise as necessary to address in the project, as it is a logging issue rather than a functional bug. I'll be sure to leave a note here if it does.

Comment by Steven Vannelli [ 04/Nov/19 ]

dianna.hohensee if fixing this bug is needed for Replicate Before Journaling project, then the Execution team can pick this up.

Generated at Thu Feb 08 05:05:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.