[SERVER-78797] Fix calculation of latest shard placement version change timestamp Created: 10/Jul/23 Updated: 27/Oct/23 Resolved: 12/Jul/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 7.1.0-rc0, 7.0.0-rc6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tommaso Tocci | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding EMEA
|
| Operating System: | ALL |
| Participants: |
| Description |
|
In Currently, this timestamp is calculated as the maximum validAfter of all chunks currently owned by the given shard. This value does not represent the latest data placement change for the shard because it does not account for the last chunk donated by the shard. In fact the timestamp of the latest donated chunk is registered on the chunk itself that after the migration commit is not part anymore of the set of owned chunk by the donor shard. |
| Comments |
| Comment by Tommaso Tocci [ 12/Jul/23 ] |
|
I've looked more into this and figure out there is no bug, in fact the getShardMaxValidAfter should return a timestamp that is greater or equal to the last time the shard has received a chunk that it currently own. |