[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: |
|
||||||||||||||||
| 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: |
| 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.
That's correct, since the topology version on mongos never changes, today we just sleep for maxAwaitTimeMS.
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.
The only information necessary to include is the information mongos currently includes in result.
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: |