[SERVER-81097] Allow the `restore` role to do all DDL on time-series buckets. Created: 15/Sep/23  Updated: 06/Feb/24

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

Type: Task Priority: Major - P3
Reporter: Felipe Gasper Assignee: Henrik Edin
Resolution: Unresolved Votes: 0
Labels: time-series-mongosync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Assigned Teams:
Storage Execution
Sprint: Execution Team 2024-02-19
Participants:

 Description   

The server forbids some DDL operations, like shardCollection and drop, on time-series buckets collections. For most applications this is sensible, but it prevents mongosync from sending a `collectionUUID` when doing these operations.

For now that's OK because mongosync only does single-threaded DDL; however, as of REP-2924 mongosync will augment preexisting namespaces, which means we'll potentially have multiple mongosyncs syncing to the same collection.

Unless we're going to disavow data integrity for time-series in these situations, then, the server will need to allow mongosync to do full DDL on time-series bucket collections. These operations should all accept `collectionUUID` as well.

I envision that, as with SERVER-77003, the server will only allow this functionality to clients with the `restore` role.



 Comments   
Comment by Felipe Gasper [ 10/Oct/23 ]

yuhong.zhang@mongodb.com Thank you for checking. This doesn’t block mongosync after all, at least until REP-2924.

Comment by Felipe Gasper [ 29/Sep/23 ]

Of note: I’m currently tracking a test failure on my time-series branch (REP-2771) where it appears that the UUID-less `drop` caused corruption on the destination due to a faulty interaction between mongosync’s initial sync and the change event application (“oplog rollover resilience”) that we run concurrently therewith.

I’m still digging into it, but this may impede us after all.

Comment by Felipe Gasper [ 26/Sep/23 ]

gregory.wlodarek@mongodb.com This doesn’t block mongosync for the immediate purpose of time-series support.

Our forthcoming many-to-one feature, though, will suffer from time-series data inconsistencies without this. We’d ideally like not to have to tell users to avoid many-to-one with time-series collections.

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