[SERVER-75790] ShardServerOpObserver does not correctly identify if it's acting as primary or secondary Created: 06/Apr/23  Updated: 29/Oct/23  Resolved: 11/Apr/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 5.0.0, 6.0.0
Fix Version/s: 7.0.0-rc0

Type: Bug Priority: Major - P3
Reporter: Jordi Serra Torrens Assignee: Jordi Serra Torrens
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding EMEA 2023-04-17
Participants:
Linked BF Score: 146

 Description   

ShardServerOpObserver uses `isStandaloneOrPrimary` to identify if the observed write was done by this node itself (i.e. primary) or from secondary oplog application.

However, the implementation of `isStandaloneOrPrimary` is flawed: It uses ReplicationCoordinator::getMemberState, which turns RS_PRIMARY as soon as the node wins the election. However, the newly-elected node may still be draining oplog. In that situation, the observer should still behave in "secondary" mode.

The correct way to implement `isStandaloneOrPrimary` is to use ReplicationCoordinator::canAcceptWritesFor (which other op_observers already use). `canAcceptWritesFor` will only turn true after oplog has been drained.



 Comments   
Comment by Githook User [ 11/Apr/23 ]

Author:

{'name': 'Jordi Serra Torrens', 'email': 'jordi.serra-torrens@mongodb.com', 'username': 'jordist'}

Message: SERVER-75790 Use `canAcceptWritesForDatabase` on ShardServerOpObserver
Branch: master
https://github.com/mongodb/mongo/commit/feef2e9047a5642a899938fbbd70764f2143f268

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