[SERVER-43832] Expose readConcern and writeConcern defaults in serverStatus Created: 04/Oct/19 Updated: 29/Oct/23 Resolved: 21/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.3 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Sheeri Cabral (Inactive) | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2020-01-27 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Specifically, I'd like the following to be exposed in serverStatus (this is from the design document):
This is for metrics, to see how many people are using it once it launches. My assumptions: If a user does not configure it, there will be no object. If a user does configure it, even to the default value, it will exist. (these are assumptions, not requirements, so if you envision something different let's talk) Example: user sets readConcern but not writeConcern: defaultRWConcern: { readConcern: "local" , } |
| Comments |
| Comment by Sheeri Cabral (Inactive) [ 27/Jan/20 ] | |||||
|
I'm OK - the goal was to have an easy way to find it out, and that's what you've done. Thanks! | |||||
| Comment by Jack Mulrow [ 21/Jan/20 ] | |||||
|
sheeri.cabral, here's a quick summary of what we ended up implementing. Let me know if there's anything you'd like to see changed! Regardless of if a user has ever set a default read or write concern, the serverStatus output for a server includes by default a "defaultReadWriteConcern" field that maps to a BSON object with the same format as a response from running getDefaultRWConcern. The contents of this object will be as follows:
So if we want to see how many users are using this feature, instead of checking for the presence of a defaultRWConcern object, we can do so by checking for the presence of either epoch or setTime in the defaultRWConcern object. | |||||
| Comment by Githook User [ 21/Jan/20 ] | |||||
|
Author: {'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}Message: | |||||
| Comment by Bruce Lucas (Inactive) [ 14/Jan/20 ] | |||||
|
That seems like a good strategy, not just because of space concerns, but also since most readConcern and writeConcern values are strings, which would not be captured in the once-per-second samples anyway (although confusingly if the w: and j: numeric values were present they would be captured). | |||||
| Comment by Kevin Pulo [ 14/Jan/20 ] | |||||
|
kaloian.manassiev and I discussed this the other day. Just to capture the outcome, this should be in a new serverStatus section, which is on by default but disabled when serverStatus is called by FTDC. At the same time, FTDC should collect getDefaultRWConcern on rotate (ie. alongside buildInfo, getCmdLineOpts, and hostInfo). This way, users and regular monitoring will see the defaults (if any) in serverStatus, and FTDC will also get the defaults but only every 5 minutes rather than every second. |