[SERVER-52896] Handle compact during tenant migrations Created: 16/Nov/20  Updated: 14/Dec/22  Resolved: 17/Nov/20

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Do Votes: 0
Labels: pm-1791_other_required
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Participants:

 Description   

TheĀ compact command rewrites and defragments all data and indexes in a collection. It does not generate oplog entries.

Note that patch set 1 of this CR forĀ SERVER-49174 contains the code for handling compact but it was decided that it should be tackled in a separate ticket.

I don't think we need to support compact during tenant migrations, since the data will be written fresh on the recipient anyway.



 Comments   
Comment by Githook User [ 14/Dec/22 ]

Author:

{'name': 'Esha Maharishi', 'email': 'esha.maharishi@mongodb.com', 'username': 'EshaMaharishi'}

Message: SERVER-52905 Complete TODO listed in SERVER-49834

There are two TODO's on SERVER-49834 in jstests/replsets/tenant_migration_concurrent_writes_on_donor_util.js: one for unskipping the captrunc command and one for unskipping the compact command.

However, SERVER-49834 is about fsyncLock and fsyncUnlock, not captrunc or compact.

The TODO for captrunc was probably meant to be on SERVER-52895, where we ultimately decided not to support captrunc or emptycapped in serverless. We later banned capped collections entirely in serverless in CLOUDP-106443. So, I just removed all testing for capped collections from this file.

The TODO for compact was probably meant to be on SERVER-52896, where we ultimately decided not to support compact in serverless. So, I similarly removed testing for compact from this file.
Branch: master
https://github.com/mongodb/mongo/commit/b23364e3a19b3821ee8a6735b304e5d7117a4930

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