[SERVER-39813] Add the oldest required timestamp into server status Created: 25/Feb/19  Updated: 29/Oct/23  Resolved: 22/May/19

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

Type: Improvement Priority: Major - P3
Reporter: Gregory McKeon (Inactive) Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: bigtxns_diagnostics, bigtxns_optional
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-39680 Maintain the oldest active transactio... Closed
related to SERVER-39812 Add the number of in-progress transac... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2019-06-03
Participants:

 Description   

Either in the repl or transaction section.



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

Author:

{'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}

Message: SERVER-39813 add oldest required timestamp to server status
Branch: master
https://github.com/mongodb/mongo/commit/fabcd95aa7c86f673387fd0143b88013168d71d6

Comment by Githook User [ 22/May/19 ]

Author:

{'email': 'benety@mongodb.com', 'name': 'Benety Goh', 'username': 'benety'}

Message: SERVER-39813 WiredTigerKVEngine::getOplogNeededForCrashRecovery() returns boost::none for read only configurations
Branch: master
https://github.com/mongodb/mongo/commit/fbb03c4cc21c495b6ce360a90a8c6dde57871ad7

Comment by Benety Goh [ 22/May/19 ]

Closing this ticket with the following two commits:

Comment by Daniel Gottlieb (Inactive) [ 16/Apr/19 ]

Apologies for being late to the party judah.schvimer. I don't see a problem surfacing that value. Or, just in the interest of presenting you with options: if you don't care exactly which response sub-object it gets thrown in, the server status for storage (perhaps WT specific?) gets filled out here.

Comment by Judah Schvimer [ 04/Apr/19 ]

For SERVER-39812 I think we'd want to cache it with an atomic counter like we do for other ServerTransactionMetrics.

Comment by Judah Schvimer [ 04/Apr/19 ]

Doing a collection scan would be unacceptable for server status, however we cache the value here and could surface that value. daniel.gottlieb, do you see any problem with that?

Comment by Siyuan Zhou [ 04/Apr/19 ]

judah.schvimer, given the change of how we store and get the oldest required timestamp, do we still want this with a transaction table scan? Is it acceptable to do a collection scan to get server status? Gating this with an option is possible. A similar question applies to SERVER-39812.

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