[SERVER-64408] VectorClock's topology time may be wrongly advanced in case of rollback Created: 10/Mar/22 Updated: 12/May/22 Resolved: 12/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Pierlauro Sciarelli | Assignee: | Sergi Mateo Bellido |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backport Requested: |
v6.0
|
||||||||||||||||||||||||
| Sprint: | Sharding EMEA 2022-04-04, Sharding EMEA 2022-04-18, Sharding EMEA 2022-05-02, Sharding EMEA 2022-05-16 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
The CSRS is registering a topology time tick point (timestamp X)when observing local inserts and applyOps modifying config.shards. On majority commit, if the timestamp of the majority committed oplog entry is greater or equal than X, the topology time is then advanced to X. The current implementation does not take into account rollbacks and may end up bumping wrongly the topology time. Example:
|
| Comments |
| Comment by Sergi Mateo Bellido [ 12/May/22 ] |
|
|
| Comment by Pierlauro Sciarelli [ 10/Mar/22 ] |
|
Considering that add/remove shard are not happening so often, a possible solution would be to not locally commit addShard and removeShard operations. Instead, we could synchronously wait for majority and then advance the topology time with the newly committed timestamp. This solution works also in case an improbale shutdown happens exactly after majority committing the entry and before advancing the topology time, because on step-up the new primary CSRS node will recover the correct topology time from disk. It would be great to throw away the unnecessarily complex ticking semantics. |