[SERVER-27226] do not uassert if earliestOptime is unavailable for the optime serverStatus section Created: 30/Nov/16  Updated: 06/Dec/22  Resolved: 20/Apr/20

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

Type: Improvement Priority: Major - P3
Reporter: Eric Milkie Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Replication
Participants:

 Description   

Currently, a node may not have an earliestOptime when in state STARTUP2 and doing an initial sync. The serverStatus command currently returns an error if you request the oplog server status section in this state. It would be better to simply not return the earliestOptime field, or to return a field that is effectively 0.



 Comments   
Comment by Chibuikem Amaechi [ 15/Jan/18 ]

I believe replacing the following fragment of code:

BSONObj o;               
uassert(17347,
        "Problem reading earliest entry from oplog",
        Helpers::getSingleton(opCtx, oplogNS.c_str(), o));
 
result.append("earliestOptime", o["ts"].timestamp());
return result.obj();

with

BSONObj o;               
if(Helpers::getSingleton(opCtx, oplogNS.c_str(), o))
    result.append("earliestOptime", o["ts"].timestamp());   
 
return result.obj();

inside OplogInfoServerStatus::generateSection() could be one way of resolving this issue.

The above change would omit the earliestOptime field from the resulting BSON object if the node was in state STARTUP2. If, however, the earliestOptime field needs to be present for whatever reason, the alternative approach would be adding the field with a value that is effectively 0.

Modified file(s): mongo/src/mongo/db/repl/replication_info.cpp

Please share your thoughts.

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