[SERVER-57287] "timeseries" is not a top-level field when running collStats on mongos Created: 28/May/21  Updated: 29/Oct/23  Resolved: 15/Jun/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.0.0-rc3, 5.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Julia Ruddy (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Fixed Votes: 0
Labels: execution-product-sync, time-series
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
is related to SERVER-57589 Enhance testing for cluster collStats... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0
Sprint: Execution Team 2021-06-14, Execution Team 2021-06-28
Participants:

 Description   

When running db.runCommand( { collStats : "timeseries" } ) on a mongos for a time-series collection, the new timeseries field does not appear at the top-level. For replica sets and standalones, timeseries is a top-level field as shown below:

 {{ "ns" : "test.timeseries", "size" : 8154720, "timeseries" : { "bucketsNs" : "test.system.buckets.timeseries", "bucketCount" : 70, "avgBucketSize" : 116496, "numBucketInserts" : 0, "numBucketUpdates" : 0, "numBucketsOpenedDueToMetadata" : 0, "numBucketsClosedDueToCount" : 0, "numBucketsClosedDueToSize" : 0, "numBucketsClosedDueToTimeForward" : 0, "numBucketsClosedDueToTimeBackward" : 0, "numBucketsClosedDueToMemoryThreshold" : 0, "numCommits" : 0, "numWaits" : 0, "numMeasurementsCommitted" : 0 } ...}

However, for a mongos the timeseries field is only available nested within the shards field. For example: 

{{ "sharded" : false, "primary" : "myShard_0", ... "shards" : { "myShard_0" : { "ns" : "test.ts", "size" : 0, "timeseries" : { "bucketsNs" : "test.system.buckets.ts", "bucketCount" : 0, "numBucketInserts" : 0, "numBucketUpdates" : 0, "numBucketsOpenedDueToMetadata" : 0, "numBucketsClosedDueToCount" : 0, "numBucketsClosedDueToSize" : 0, "numBucketsClosedDueToTimeForward" : 0, "numBucketsClosedDueToTimeBackward" : 0, "numBucketsClosedDueToMemoryThreshold" : 0, "numCommits" : 0, "numWaits" : 0, "numMeasurementsCommitted" : 0 }, ... }, ...} 

I would think the timeseries field would also be at the top-level similar to the ns, size, storageSize, totalIndexSize, totalSize, indexSizes etc fields. If this is expected behavior, however, feel free to close this ticket.



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 17/Jun/21 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}

Message: SERVER-57287 Pull the shards' summed 'timeseries' field values to the top-level of the cluster
collStats command response

(cherry picked from commit 91ce36557dc90c85544791a47f880509ada6469e)
Branch: v5.0
https://github.com/mongodb/mongo/commit/79cc015b4294ef55f4e09d12ab5bc0b95bc3a853

Comment by Githook User [ 15/Jun/21 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}

Message: SERVER-57287 Pull the shards' summed 'timeseries' field values to the top-level of the cluster
collStats command response
Branch: master
https://github.com/mongodb/mongo/commit/91ce36557dc90c85544791a47f880509ada6469e

Comment by Dianna Hohensee (Inactive) [ 09/Jun/21 ]

I've filed SERVER-57589 as follow up testing for when sharded timeseries collections are supported. This ticket will only handle the single-shard scenario testing, as that's all that can run right now.

Comment by Julia Ruddy (Inactive) [ 07/Jun/21 ]

We implemented a workaround to check for the timeseries field on the nested shard document for now. If it is not straightforward, ok with me to move to PM-2188.

Comment by Daniel Gottlieb (Inactive) [ 01/Jun/21 ]

Hi julia.ruddy, I've passed this to storage execution (they did the time series project) to see if this is intentional, although this might be more of a sharding clarification. I think historically sharding has had trouble ensuring all shards have a consistent definition for a collection and its indexes. For those circumstances, it's obviously beneficial to have a schema that can express those situations.

Generated at Thu Feb 08 05:41:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.