[SERVER-60020] Remove special handling for cases when only time-series view exists Created: 16/Sep/21  Updated: 27/Dec/23

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

Type: Improvement Priority: Major - P3
Reporter: Nikita Lapkov (Inactive) Assignee: Backlog - Query Integration
Resolution: Unresolved Votes: 0
Labels: neweng, qi-timeseries, read-only-views, tscs-ramp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-59126 drop collection on time-series collec... Closed
Assigned Teams:
Query Integration
Participants:

 Description   

At the moment of writing, there can be a situation when time-series view exists, but time-series buckets collection does not. This can happen when the user directly drops time-series buckets collection, for example.

For such situations, we have special handling in multiple places. See listCollections command as an example.

After SERVER-59126 is merged, the time-series view will be always deleted when the time-series buckets collection is deleted. This renders the situation when only time-series view exists impossible. In turn, this means that the special handling is no longer necessary for this case. We should remove it.



 Comments   
Comment by Gregory Noma [ 02/Jul/22 ]

I don't think we can block FCV upgrade like that. For instance imagine a serverless environment; it wouldn't be acceptable to block FCV upgrade because of one tenant on that cluster.

An alternative could be to create a sort of "default" buckets collection during FCV upgrade in that scenario, but that idea has some issues as well. One issue would be what to use for timeField which is required to be specified by the user upon time-series collection creation. Worse yet, what if there's a collection that "looks like" a corresponding buckets collection based on its name, but doesn't actually have the correct options to be a buckets collection?

Comment by Mickey Winters [ 01/Jul/22 ]

yeah I agree with the fcv check, we need to do this at some point so we aren't permanently stuck worrying about the scenario greg pointed out

Comment by Jennifer Peshansky (Inactive) [ 01/Jul/22 ]

I think we should do this as part of FCV upgrade behavior. When a user attempts to upgrade their FCV, we check for a timeseries view without an underlying buckets collection (and probably the inverse, a buckets collection without a timeseries view) and block FCV upgrade until they delete the offending collection/view(s). This would also solve a similar issue SERVER-67676 will create; even once we ban creating a buckets collection without a timeseries view, the user could always have gotten into that state before the ticket. cc mickey.winters@mongodb.com gregory.noma@mongodb.com nikita.lapkov@mongodb.com

Note that since SERVER-59126 ensures that dropping either a buckets collection or a time series view will drop the other, and SERVER-67676 bans creating a buckets collection on its own, and creating a timeseries collection already creates an underlying buckets collection, we will create a situation where one can never exist without the other unless that state was achieved before upgrade. If we enforce this on upgrade we can always work under this assumption going forward.

Comment by Gregory Noma [ 28/Jun/22 ]

In terms of what this ticket is currently proposing, I'm actually not sure if there's much we can do here since a user could have always gotten into this state before we did SERVER-59126.

Comment by Mickey Winters [ 28/Jun/22 ]

gregory.noma@mongodb.com potentially should we be checking that as part of some startup task to check integrity?

Comment by Gregory Noma [ 11/Oct/21 ]

One thing we may need to take into consideration here is the case where someone dropped only the buckets collection before we made doing so also drop the view.

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