[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:
Duplicate
duplicates SERVER-27772 processing afterClusterTime > cluster... Closed
Related
is related to SERVER-27772 processing afterClusterTime > cluster... Closed
is related to SERVER-12119 Add new command to allow applications... Closed
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 SERVER-27772

Generated at Thu Feb 08 04:18:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.