[SERVER-31094] Mongos should fail gracefully when pointing to a featureCompatibilityVersion 3.6 cluster Created: 14/Sep/17  Updated: 10/Jan/18  Resolved: 21/Sep/17

Status: Closed
Project: Core Server
Component/s: Internal Code, Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Louis Williams
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32635 Provide a framework to ensure a last ... Closed
is related to SERVER-29428 Make 3.4 mongod fail gracefully in fe... Closed
Sprint: Storage 2017-10-02
Participants:

 Description   

This is continuation of SERVER-29428:

When pointing a 3.4 mongos at a featureCompatibilityVersion=3.6 cluster, the mongos spins, logging:
remote host has incompatible wire version: IncompatibleServerVersion: Server
min and max wire version are incompatible (6,6) with client min wire version
(5,5)
Instead, the processes should quickly exit with a non-zero exit code and a useful error message. The error message should display a "MustUpgrade" error code and should link to the documentation for the 3.4=>3.6 upgrade process.

This is not possible because mongos uses a DBConnectionPool, which uses a MongoURI that does not return a status code, but sets an error string. MongoURI::connect should return a StatusWith<DBClientConnection> to determine the reason for connection failure, which can be checked in Refresher::_refreshUntilMatches in replica_set_monitor.cpp

DBClientBase* DBConnectionPool::get(const MongoURI& uri, double socketTimeout) {
     std::unique_ptr<DBClientBase> c(_get(uri.toString(), socketTimeout));
     if (c) {
         onHandedOut(c.get());
         return c.release();
     }
 
     string errmsg;
     c = std::unique_ptr<DBClientBase>(uri.connect(StringData(), errmsg, socketTimeout));
     uassert(40356, _name + ": connect failed " + uri.toString() + " : " + errmsg, c);
 
     return _finishCreate(uri.toString(), socketTimeout, c.release());
}



 Comments   
Comment by Esha Maharishi (Inactive) [ 17/Oct/17 ]

If the ReplicaSetMonitor is refactored in 3.8 to use ASIO, this may become very simple, since the ReplicaSetMonitor can check the error code directly in the RemoteCommandResponse.

CC redbeard0531

Comment by Louis Williams [ 21/Sep/17 ]

The unintended consequences of this behavior are undesirable. See SERVER-29428

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