[SERVER-46955] Create the MongosTopologyCoordinator Created: 18/Mar/20  Updated: 29/Oct/23  Resolved: 23/Apr/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Pavithra Vetriselvan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-46956 Add quiesce mode to the MongosTopolog... Closed
Related
is related to SERVER-47750 ismaster server response now returns ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2020-04-06, Repl 2020-04-20, Repl 2020-05-04
Participants:

 Description   

Move the mongosTopologyVersion into a class, MongosTopologyCoordinator, which is responsible for constructing isMaster responses. Make isMaster requests wait on a Future for topology changes, similar to the ReplicationCoordinator. Consider sharing code with the ReplicationCoordinator.



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

Author:

{'name': 'Pavi Vetriselvan', 'email': 'pvselvan@umich.edu', 'username': 'pvselvan'}

Message: SERVER-46955 Create MongosTopologyCoordinator
Branch: master
https://github.com/mongodb/mongo/commit/622592c8cd4801d88d5a5cdf9933ec200f1aa2b0

Comment by Pavithra Vetriselvan [ 20/Apr/20 ]

Code review url: https://mongodbcr.appspot.com/578970001/

Comment by Tess Avitabile (Inactive) [ 13/Apr/20 ]

pavithra.vetriselvan, thank you for checking in about these questions.

Currently, in cluster_is_master_cmd.cpp, we do not wait for the mongosTopologyVersion to change since mongos never previously changed the topology version. With this project, we will change the topology version on mongos (once we enter Quiesce mode?) so mongos must respond to isMaster requests with ok: 0.

That's correct, since the topology version on mongos never changes, today we just sleep for maxAwaitTimeMS.

Question #1: Until we implement Quiesce Mode on mongos, will we just timeout waiting for the isMaster response? I'm assuming the topologyVersion still wouldn't change.

That's correct, until we start calling MongosTopologyCoordinator::enterQuiesceMode(), the topology version on mongos will never change, so MongosTopologyCoordinator::awaitIsMasterResponse() will always time out and return a response after maxAwaitTimeMS.

Question #2: This above metadata is unnecessary for the mongos implementation, but is there anything else we should be including?

The only information necessary to include is the information mongos currently includes in result.

Question #3: Sanity check. Mongos doesn't support horizons, right?

Correct

Comment by Pavithra Vetriselvan [ 13/Apr/20 ]

tess.avitabile, just wanted to summarize my understanding of the goals here and propose a solution:

Currently, in cluster_is_master_cmd.cpp, we do not wait for the mongosTopologyVersion to change since mongos never previously changed the topology version. With this project, we will change the topology version on mongos (once we enter Quiesce mode?) so mongos must respond to isMaster requests with ok: 0.

Question #1: Until we implement Quiesce Mode on mongos, will we just timeout waiting for the isMaster response? I'm assuming the topologyVersion still wouldn't change.

Since mongos should start constructing isMaster responses depending on topology version changes, we would like to create a new class, MongosTopologyCoordinator. From my understanding, this class will be responsible for maintaining mongosTopologyVersion and returning isMaster responses based on changes to it.

We will need to implement something like MongosTopologyCoordinator::awaitIsMasterResponse. It seems like for mongos, we really only care about the topology version changing. In replication, we append extra information to the response about the node's state, last majority write, other members, etc.

Question #2: This above metadata is unnecessary for the mongos implementation, but is there anything else we should be including?

Question #3: Sanity check. Mongos doesn't support horizons, right?

Re: sharing code with ReplicationCoordinator:
Since a lot of the replication coordinator's version for awaitIsMasterResponse seems specific to replica set nodes, I think it would be easier to see what code is actually shared between the two implementations. We could then consider making it cleaner in a follow-up commit.

Generated at Thu Feb 08 05:12:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.