[SERVER-61231] Adapt migration tests for shard merge Created: 03/Nov/21 Updated: 29/Oct/23 Resolved: 18/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Didier Nadeau |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | shard-merge-milestone-3 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Serverless
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Sprint: | Server Serverless 2023-05-01 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
UPDATE: (Review all the files with :TODO Some multitenant migration tests do "banned operations" that the new shard merge protocol can't handle:
Sometimes they do banned ops specifically to test whether they work with migrations. We know that shard merge will never support these ops, so we can disable these tests when featureFlagShardMerge is enabled. Eventually we'll delete these tests when shard merge becomes the only migration protocol. Other tests happen to do banned ops and they also test other features, for which we don't want to lose coverage when featureFlagShardMerge is enabled. E.g. tenant_migration_external_keys_ttl.js does concurrent migrations but also tests a TTL index. Adapt these tests somehow: either don't do banned ops, or do them only when featureFlagShardMerge is disabled, or make a copy of the test for shard merge and remove the banned ops. |
| Comments |
| Comment by Githook User [ 18/Apr/23 ] |
|
Author: {'name': 'Didier Nadeau', 'email': 'didier.nadeau@mongodb.com', 'username': 'nadeaudi'}Message: |
| Comment by A. Jesse Jiryu Davis [ 02/Feb/22 ] |
|
I think the fsync question is tracked in |
| Comment by Suganthi Mani [ 02/Feb/22 ] |
|
Note: We should also make sure we run fsync on donor before starting a migration for shard merge protocol. This is needed to ensure that whatever writes made on donor before migration appears in the backup cursor's checkpoint. |