[SERVER-24688] Graceful shutdown without destroying the current cmd Created: 21/Jun/16 Updated: 08/Feb/23 Resolved: 15/Jul/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Tommaso Allevi | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | move-sa, platforms-re-triaged | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Repl 2020-07-27 | ||||||||
| Participants: | |||||||||
| Description |
| Comments |
| Comment by Tess Avitabile (Inactive) [ 15/Jul/20 ] |
|
Hi allevo, Thank you for this feature request. In response to requests for a more graceful shutdown on mongod and mongos, we've implemented the quiesce mode feature: mongod secondaries and mongos will enter a quiesce mode prior to shutdown, to allow short-running operations to finish. During this time, new and existing operations are allowed to run, but isMaster requests return a ShutdownInProgress error, to indicate that clients should start routing operations to other nodes. On mongod, quiesce mode happens after the stepdown attempt, and only if the node is now in state SECONDARY. The combined time for stepdown and quiesce mode is specified by the timeoutSecs parameter to the shutdown command (for command-based shutdown) or the shutdownTimeoutMillisForSignaledShutdown/mongosShutdownTimeoutMillisForSignaledShutdown server parameter (for signaled shutdown). This work is completed as of Kind regards, Tess |
| Comment by Kelsey Schubert [ 22/Jun/16 ] |
|
Hi allevo, Thank you for clarifying this feature request. I've updated the ticket description to reflect your latest comment and have marked this ticket to be considered during the next round of planning. Please continue to watch for updates Kind regards, |
| Comment by Tommaso Allevi [ 22/Jun/16 ] |
|
The problem is clear: according to the theory, in a production environment, when the high availability is required, the application has to trust in its database. No undefined behavior should be permitted. I'm thinking when our DBA team is upgrading mongos cluster. I suppose the expected behavior during a graceful shutdown is like this:
|
| Comment by Ramon Fernandez Marina [ 21/Jun/16 ] |
|
allevo, what's the behavior you think would make sense? If the mongos is shut down the client can no longer receive any information from the server. We can turn this ticket into a feature request, but it needs a better definition of the expected behavior, so can you please provide additional details? Thanks, |