[SERVER-28559] appendOplogNote command needs to ensure it's still primary after taking locks Created: 30/Mar/17 Updated: 27/Oct/23 Resolved: 18/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Repl 2017-10-02, Repl 2017-10-23 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
The append oplog note command relies on the command subsystem to prevent it from running when it's a secondary, but that check is inherently racy as it's not holding any db locks at that point. Also, the appendOplogNote command currently takes a global write lock, which is unnecessary heavy. The command should be changed to take the global lock in mode IX, check that it's still primary, and then proceed with calling onOpMessage to write the no-op oplog entry (which takes a write lock on the oplog internally). |
| Comments |
| Comment by Spencer Brody (Inactive) [ 18/Oct/17 ] |
|
Looks like this was already taken care of in |