[SERVER-44914] A shard receiving its first chunk should locally drop any indexes not on the donor Created: 02/Dec/19 Updated: 29/Oct/23 Resolved: 03/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.3 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Mihai Andrei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Sharding 2019-12-16, Sharding 2019-12-30, Sharding 2020-01-13 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
From the design document:
The recipient shard should verify its DatabaseShardingState is up to date before checking if it is the primary shard. |
| Comments |
| Comment by Githook User [ 20/Dec/19 ] |
|
Author: {'name': 'Mihai Andrei', 'email': 'mihai.andrei@mongodb.com'}Message: |
| Comment by Jack Mulrow [ 19/Dec/19 ] |
|
To keep the primary shard the authoritative source for the collections on a database (unsharded and sharded) we changed this ticket so the recipient will only drop its indexes when receiving its first chunk, instead of dropping the collection. |
| Comment by Jack Mulrow [ 12/Dec/19 ] |
|
After further discussion, we're dropping the requirement that the primary shard always has correct indexes when it has no chunks, so step 1) from my first comment is unnecessary. |
| Comment by Jack Mulrow [ 12/Dec/19 ] |
|
Spoke offline with esha.maharishi and she pointed out that the recipient shard in a migration already refreshes its metadata before cloning documents, so we can simplify the implementation from my comment if we move the refresh after the recipient registers the migration. With that change, the recipient should be able to always use its latest CollectionMetadata to check if it owns chunks without needing another refresh. She also pointed out that getting the primary shard id from the CatalogCache is unsafe even after a database refresh. Instead we can start storing the primary shard id in the DatabaseShardingState and use that, but since we're reconsidering the requirement that the primary shard has authoritative indexes, we might be able to throw out the primary check entirely. |
| Comment by Jack Mulrow [ 11/Dec/19 ] |
|
esha.maharishi, can you look over the following proposed implementation? The main idea is that because a shard can only be the recipient in one migration at a time, if it refreshes during the receiving logic, it should know definitively if it owns any chunks. I figure adding a refresh to each migration isn't great though, so I added some optimizations to avoid refreshes in most cases.
Technically it's possible after refreshing in step 3 the recipient moves away its last chunk and incorrectly decides it doesn't need to drop the collection in step 4, but I don't think this is a problem because mongos shard versions index operations. If there's a concurrent index operation it must target the shard donating a chunk to this recipient, and the operation will either execute on that donor before this migration reaches its critical section, which will abort the migration, or it executes after and the command will fail with StaleConfig and be retried, and the retry should correctly target the recipient. |