[SERVER-57754] Tenant Oplog Applier doesn't grab the RSTL before reserving oplog slots Created: 16/Jun/21 Updated: 29/Oct/23 Resolved: 17/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc3, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Vishnu Kaushik | Assignee: | Vishnu Kaushik |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | post-rc0 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v5.0
|
||||||||||||
| Sprint: | Repl 2021-06-28 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 167 | ||||||||||||
| Description |
|
The tenant oplog applier doesn't grab the RSTL via AutoGetOplog before reserving oplog slots here, the way it does elsewhere. This needs to be added. Currently, it's possible for the primary (on which the tenant oplog applier exists) to stepdown, but have the applier continue to run. This may cause a clash with the secondary oplog fetcher, and cause the stable timestamp to move ahead of the all durable timestamp, triggering an fassert. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 22/Jun/21 ] |
|
Author: {'name': 'Vishnu Kaushik', 'email': 'vishnu.kaushik@mongodb.com', 'username': 'kauboy26'}Message: |
| Comment by Githook User [ 17/Jun/21 ] |
|
Author: {'name': 'Vishnu Kaushik', 'email': 'vishnu.kaushik@mongodb.com', 'username': 'kauboy26'}Message: |