[DRIVERS-2054] SDAM updates topology from new connection handshake of secondary that was previously a primary Created: 17/Mar/17  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: SDAM
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Jeremy Mikola Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Driver Changes: Needed

 Description   

SPEC-863 describes a case where a restarted primary from a 3-node replica set was selected for a write operation. This selection was based on outdated topology information, as the restart and application write occurred during a heartbeat interface. Since the restarted node had no previous connections, a new connection was made and a subsequent isMaster command was issued. In that response, the node identified itself as a secondary and a separate node as the new primary.

This isMaster response resulted in libmongoc logging "Transitioning to RSWithPrimary for RSSecondary". I believe this transition currently jibes with the TopologyType Table in the spec, since the topology's state was ReplicaSetWithPrimary at this point; however, the isMaster response from this restarted node (previously a primary and now a secondary) conflicts with the existing topology as reported from the other two nodes in the last heartbeat. In this case, it may not make sense to trust this node as an authority on the topology state until the real primary can affirm the same in a subsequent isMaster.



 Comments   
Comment by Shane Harvey [ 18/May/20 ]

I think we could resolve this ticket by adding an SDAM spec test that simulates the issue in the description:

  1. Nodes P, S1, S2, with topology type RSWithPrimary.
  2. Node P, responds as a secondary and claims that S1 is the new primary.
  3. Assert that the new topology type is RSWithoutPrimary and that node S1 is in the PossiblePrimary state.

This tests the PossiblePrimary logic in theĀ updateRSWithPrimaryFromMember routine.

Comment by Jeremy Mikola [ 18/May/20 ]

The original context for this ticket was single-threaded SDAM, so I don't think streamable isMaster would necessarily address the full issue.

Comment by Bernie Hackett [ 13/May/20 ]

shane.harvey, jeff.yemin, matt.broadstone will streamable ismaster solve this problem?

Comment by Oleg Pudeyev (Inactive) [ 27/Nov/18 ]

Is this ticket referring to outdated language in the spec? Given current wording, response from a secondary should not change the descriptions of any servers other than itself (i.e. it can't make another server primary).

Comment by Rathi Gnanasekaran [ 14/Mar/18 ]

jmikola and jesse moving this to the backlog.

Generated at Thu Feb 08 08:24:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.