[SERVER-35449] Return the oldest read timestamp used by any open transaction Created: 06/Jun/18 Updated: 29/Oct/23 Resolved: 29/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.7, 4.1.6 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Jason Chan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | nyc, prepare_diagnostics, prepare_optional | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||||||||||||||
| Sprint: | Storage NYC 2018-07-02, Repl 2018-11-19, Repl 2018-12-03 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
For transactions diagnostics support, we would like to have a way to know what the oldest read timestamp in use by any open transaction is. We would like to integrate this metric into the transactions section of serverStatus. |
| Comments |
| Comment by Githook User [ 26/Feb/19 ] |
|
Author: {'name': 'Jason Chan', 'email': 'jason.chan@mongodb.com'}Message: (cherry picked from commit 35f465029fdccee1a3b7e3b8fb91a2ea75b9aca7) |
| Comment by Githook User [ 29/Nov/18 ] |
|
Author: {'name': 'Jason Chan', 'email': 'jason.chan@mongodb.com'}Message: |
| Comment by Eric Milkie [ 02/Jul/18 ] |
|
I have agreement from william.schultz that we simply need to surface the oldest read timestamp on any open transaction from WiredTiger, so we need to start with a WT ticket. |
| Comment by William Schultz (Inactive) [ 22/Jun/18 ] |
|
dianna.hohensee I am checking in with milkie before I go ahead and file a ticket against the WiredTiger project. Once I get feedback from him, we can decide what to do with this ticket. |
| Comment by Dianna Hohensee (Inactive) [ 22/Jun/18 ] |
|
william.schultz I think we can close this, right? Since repl is going to request earliest active reader from the WT layer? Or maybe put this on hold until we resolve what WT folks can do. Though, thinking about Alex's comment above, I'm wondering what timestamp replication will want to act upon in the case of no active/open WT transactions? |
| Comment by Ben Judd [ 21/Jun/18 ] |
|
bruce.lucas Per the wired tiger docs it seems that we will be unable to get the oldest timestamp that is pinned by a MongoDB transaction without doing a scan of the open transactions. WT only returns the minimum of the oldest timestamp of the snapshot window and the read timestamps of all active readers. What we can do instead is return the this minimum value as well which can then be compared with oldest_timestamp to see WT is being forced to keep data around? |
| Comment by Alexander Gorrod [ 20/Jun/18 ] |
|
I was a bit misleading when saying statistics - the information is more readily available via the WT_CONNECTION::query_timestamp API - I believe oldest is what you are looking for here - though exact information is a bit different than described here. You'll need to think about corner cases, for example if there are no open transactions. |
| Comment by William Schultz (Inactive) [ 20/Jun/18 ] |
|
Correct. The oldest timestamp in use among all open transactions in the entire server. |
| Comment by Ben Judd [ 20/Jun/18 ] |
|
To clarify this is the single oldest timestamp in use among all open transactions, not the oldest timestamp in use by a specific single transaction, correct? |
| Comment by Alexander Gorrod [ 08/Jun/18 ] |
|
william.schultz if it helps WiredTiger already maintains that information in our statistics - you could query it from there, unless you are interested in knowing the state MongoDB is aware of independent of WiredTiger |
| Comment by William Schultz (Inactive) [ 06/Jun/18 ] |
|
I'm not sure if the infrastructure for implementing this is already in place or not, but I created this ticket to track the inclusion of this "oldestOpen" information in serverStatus output. |