[SERVER-76805] Granularity field automatically added to manually-created time-series buckets collections on v6.1- but not v6.2+ Created: 03/May/23  Updated: 10/Nov/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Gregory Noma Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: former-storex-namer, mongosync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-83114 Default timeseries options may lead t... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:
Linked BF Score: 3

 Description   

Consider manually creating a time-series buckets collection with options {timeField: "t"}. After SERVER-67598 (i.e. as of v6.2), the requested buckets collection will get created with these exact options as specified. However, before SERVER-67598 (i.e. before v6.2), when issuing this same command it will automatically by transformed to {timeField: "t", granularity: "seconds"}. This is because in the IDL definition of the time-series options, the granularity field is now considered optional whereas previously it was considered non-optional with a default value of "seconds" if not explicitly specified.

In either case the collection should functionally be the same (since "seconds" is the default behavior), however now consider the scenario where a mixed-version replica set is running with a primary node on version v6.2 (or v6.3 or v7.0) and a secondary node on version v6.1 (or v6.0). The primary node will create the collection and replicate the operation without the granularity in the collection options. However, the secondary node will implicitly add the granularity when applying the oplog entry. This means that the exact catalog entry for this collection will differ between the two nodes; it will explicitly have the granularity specified on one node and it will be excluded on the other node.


Generated at Thu Feb 08 06:33:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.