[SERVER-66899] Support multi-collection shardVersions/dbVersions in the sharding version protocol. Created: 31/May/22 Updated: 06/Dec/22 Resolved: 08/Jul/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | sharding-product-sync | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Sharding EMEA
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
The query SBE engine can access multiple collections at once via AutoGetCollection* helpers (so acquires multiple locks and accesses multiple Collection instances at once), but is currently limited to collections within the same database and only allowing a single collection to be sharded while the rest must be verified unsharded. |
| Comments |
| Comment by Kaloian Manassiev [ 08/Jul/22 ] |
|
The semantics of multiple database/collection versions is a way for a RouterRole to indicate to the ShardRole that it wants the relative placement of two database primaries/collection placement with respect to each other to be correct. The use-cases and the semantics of this are to be decided under WRITING-11362. For now, there are no use-cases for this. |
| Comment by Kaloian Manassiev [ 02/Jun/22 ] |
|
dianna.hohensee@mongodb.com, to whom can we talk more about the use-case for this feature? Multiple database/collection versions is not what most people think it is. |