[SERVER-39831] Never update commit point beyond last applied if learned from sync source Created: 25/Feb/19 Updated: 29/Oct/23 Resolved: 01/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.13, 4.1.10, 4.0.10 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Siyuan Zhou | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | RF | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||||||||||||||
| Sprint: | Repl 2019-03-25, Repl 2019-04-08 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 16 | ||||||||||||||||||||
| Description |
|
We can relax the term check when learning from sync source but only update its commit point to min(commit point, my last applied). Given that requiring the term check on learning commit point ensures that the commit point is always on a node's branch, spanning tree ensures the syncing node is on the same branch as the sync source, so the syncing node knows it's on the same branch as the commit point even if they have different terms. This ticket also fixes the issue where a secondary learns of the commit point in higher term from sync source, then syncs from another node on a diverged branch in lower term and marks the diverged branch committed by mistake. Thus this needs to be backported to earlier versions. |
| Comments |
| Comment by Githook User [ 17/Apr/19 ] |
|
Author: {'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}Message: (cherry picked from commit 1c54cae8d57f6ab29c155a2a8edeb12da71c18d5) |
| Comment by Githook User [ 17/Apr/19 ] |
|
Author: {'name': 'Tess Avitabile', 'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com'}Message: |
| Comment by Githook User [ 04/Apr/19 ] |
|
Author: {'name': 'Tess Avitabile', 'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com'}Message: |
| Comment by Githook User [ 04/Apr/19 ] |
|
Author: {'name': 'Tess Avitabile', 'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com'}Message: |
| Comment by Githook User [ 02/Apr/19 ] |
|
Author: {'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}Message: |
| Comment by Githook User [ 02/Apr/19 ] |
|
Author: {'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}Message: |
| Comment by Githook User [ 01/Apr/19 ] |
|
Author: {'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}Message: |
| Comment by Tess Avitabile (Inactive) [ 26/Feb/19 ] |
|
Oh, got it. |
| Comment by Tess Avitabile (Inactive) [ 26/Feb/19 ] |
|
siyuan.zhou, I don't follow why this doesn't fix the problem of |
| Comment by Siyuan Zhou [ 25/Feb/19 ] |
|
I just realized this won't fix the problem of If we have to choose, I'd vote for this one, since we've never seen the invariant in |
| Comment by Tess Avitabile (Inactive) [ 25/Feb/19 ] |
|
siyuan.zhou, do you think I should close |