[SERVER-40565] Omit last applied and last durable wall clock times from replSetGetStatus when associated optimes are null Created: 10/Apr/19  Updated: 29/Oct/23  Resolved: 11/Apr/19

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

Type: Task Priority: Major - P3
Reporter: Maria van Keulen Assignee: Maria van Keulen
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-40080 Add lastApplied and lastDurable wall ... Closed
is related to SERVER-40737 Use Date_t() as default wallTime valu... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0, v3.6
Sprint: Storage NYC 2019-04-22
Participants:
Linked BF Score: 35

 Description   

As of SERVER-40080, last applied and last durable wall clock times are included in replSetGetStatus. When their associated optimes are null, the corresponding wall clock time value is Date_t::min(). The python driver is unable to parse this quantity, so these fields should be omitted from replSetGetStatus.



 Comments   
Comment by Judah Schvimer [ 17/Jul/19 ]

Thank you maria.vankeulen. I will decline backports of this ticket and we've already approved backports of SERVER-40737 and SERVER-40080.

Comment by Maria van Keulen [ 17/Jul/19 ]

judah.schvimer The pertinent ticket to backport is actually SERVER-40737. SERVER-40565 is not necessary if SERVER-40737 is backported. And yes, it is still necessary to backport SERVER-40737 even if we're only backporting SERVER-40080.

Comment by Judah Schvimer [ 16/Jul/19 ]

maria.vankeulen, should this be backported if we're backporting SERVER-40080 but not SERVER-40078 or SERVER-40353?

Comment by Githook User [ 11/Apr/19 ]

Author:

{'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}

Message: SERVER-40565 Only append valid wall times to replSetGetStatus optimes
Branch: master
https://github.com/mongodb/mongo/commit/a9c139de1c4e9cc282f9ec60fcea0a790e979fd1

Comment by Maria van Keulen [ 11/Apr/19 ]

Not sure why the githook didn't run here. The fix follows: https://github.com/mongodb/mongo/commit/a9c139de1c4e9cc282f9ec60fcea0a790e979fd1

Comment by Kelsey Schubert [ 10/Apr/19 ]

Sounds reasonable to me. Thanks for thinking of FTDC!

Comment by Maria van Keulen [ 10/Apr/19 ]

I noticed from my local testing of this patch that readConcernMajorityOpTime is also omitted from the replSetGetStatus optimes subdocument when lastCommittedOpTime, appliedOpTime, and durableOpTime are null, so if it's acceptable to omit this optime, I think it should also be acceptable to omit the last applied and last durable wall clock times during this window.

Comment by Eric Milkie [ 10/Apr/19 ]

judah.schvimer the document shape would only be changing once per initial sync attempt, so I'm confident there will be no compression issues here.

Comment by Judah Schvimer [ 10/Apr/19 ]

kelsey.schubert, is this fine? I forget if FTDC keeps track of replSetGetStatus and I know fields that change document shape can cause compression issues.

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