alcaeus
commented
3 years ago Hi @H-Max! First of all, sorry for the delay in getting back to you. I played around with this a couple of times but never got around to finishing my write-up.
I tried to reproduce this locally, where I have a sharded cluster with two mongos instances listening on ports 4430 and 4431. I created a MongoDB\Client instance with an additional (unreachable) host in the first position:
$cluster = 'mongodb://localhost:4429,localhost:4430,localhost:4431';
$client = new MongoDB\Client($cluster, ['serverSelectionTimeoutMS' => 2000]);
for ($i = 0; $i < 5; $i++) {
echo "ping...";
$result = $client->selectDatabase('test')->command(['ping' => 1]);
echo "pong: " . $result->getServer()->getPort() . "\n";
}The output from this script is as follows:
ping...pong: 4430
ping...pong: 4431
ping...pong: 4430
ping...pong: 4431
ping...pong: 4430Dumping the list of servers (in this case their host and port only) shows only two servers:
array(2) {
[0] =>
string(14) "localhost:4430"
[1] =>
string(14) "localhost:4431"
}I was also able to confirm that libmongoc (which handles connecting to servers) correctly skips the unknown server by setting the mongodb.debug setting to log to stdout. Among the entire trace output we can see this:
[2020-11-10T14:54:53.584899+00:00] socket: TRACE > ENTRY: _mongoc_socket_wait():161
[2020-11-10T14:54:53.584927+00:00] socket: TRACE > EXIT: _mongoc_socket_wait():226
[2020-11-10T14:54:53.584934+00:00] socket: TRACE > EXIT: mongoc_socket_connect():890
[2020-11-10T14:54:53.584939+00:00] stream: TRACE > ENTRY: _mongoc_stream_socket_poll():227
[2020-11-10T14:54:53.584980+00:00] socket: TRACE > ENTRY: mongoc_socket_poll():297
[2020-11-10T14:54:53.585008+00:00] stream: TRACE > EXIT: _mongoc_stream_socket_poll():253
[2020-11-10T14:54:53.585013+00:00] stream: TRACE > ENTRY: mongoc_stream_failed():80
[2020-11-10T14:54:53.585017+00:00] stream: TRACE > ENTRY: _mongoc_stream_socket_failed():93
[2020-11-10T14:54:53.585020+00:00] stream: TRACE > ENTRY: _mongoc_stream_socket_destroy():72
[2020-11-10T14:54:53.585023+00:00] socket: TRACE > ENTRY: mongoc_socket_close():790
[2020-11-10T14:54:53.585038+00:00] socket: TRACE > EXIT: mongoc_socket_close():825
[2020-11-10T14:54:53.585042+00:00] stream: TRACE > EXIT: _mongoc_stream_socket_destroy():86
[2020-11-10T14:54:53.585045+00:00] stream: TRACE > EXIT: _mongoc_stream_socket_failed():97
[2020-11-10T14:54:53.585048+00:00] stream: TRACE > EXIT: mongoc_stream_failed():90
[2020-11-10T14:54:53.585077+00:00] mongoc: TRACE > TRACE: _mongoc_topology_clear_connection_pool():1601 clearing pool for server: localhost:4429
[2020-11-10T14:54:53.585130+00:00] mongoc: TRACE > TRACE: mongoc_topology_description_handle_ismaster():1974 ismaster_response = <NULL>
[2020-11-10T14:54:53.585172+00:00] mongoc: TRACE > ENTRY: mongoc_server_description_handle_ismaster():527
[2020-11-10T14:54:53.585184+00:00] mongoc: TRACE > EXIT: mongoc_server_description_handle_ismaster():534
[2020-11-10T14:54:53.585256+00:00] mongoc: TRACE > TRACE: mongoc_topology_description_handle_ismaster():2031 Topology description Unknown ignoring server description Unknown
[2020-11-10T14:54:53.585292+00:00] mongoc: TRACE > ENTRY: mongoc_server_description_destroy():163
[2020-11-10T14:54:53.585296+00:00] mongoc: TRACE > EXIT: mongoc_server_description_destroy():166libmongoc tries to connect to the first server, fails and removes it from the topology. Later, it successfully looks up the other two servers and deduces it is connected to a sharded cluster:
[2020-11-10T14:54:53.586473+00:00] mongoc: TRACE > TRACE: mongoc_topology_description_handle_ismaster():1974 ismaster_response = { "ismaster" : true, "msg" : "isdbgrid", "topologyVersion" : { "processId" : { "$oid" : "5fa8f972bc83d763e94547de" }, "counter" : { "$numberLong" : "0"} }, "maxBsonObjectSize" : { "$numberInt" : "16777216" }, "maxMessageSizeBytes" : { "$numberInt" : "48000000" }, "maxWriteBatchSize" : { "$numberInt" : "100000" }, "localTime" : { "$date" : { "$numberLong" : "1605020093583" } }, "logicalSessionTimeoutMinutes" : { "$numberInt" : "30" }, "connectionId" : { "$numberInt" : "1011" }, "maxWireVersion" : { "$numberInt" : "10" }, "minWireVersion" : { "$numberInt" : "0" }, "ok" : { "$numberDouble" : "1.0" }, "$clusterTime" : { "clusterTime" : { "$timestamp" : { "t" : 1605020088, "i" : 3 } }, "signature" : { "hash" : { "$binary" : { "base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "subType" : "00" } }, "keyId" : { "$numberLong" : "0"} } }, "operationTime" : { "$timestamp" : { "t" : 1605020088, "i" : 3 } } }
[2020-11-10T14:54:53.586481+00:00] mongoc: TRACE > ENTRY: mongoc_server_description_handle_ismaster():527
[2020-11-10T14:54:53.586803+00:00] mongoc: TRACE > EXIT: mongoc_server_description_handle_ismaster():725
[2020-11-10T14:54:53.586838+00:00] mongoc: TRACE > TRACE: mongoc_topology_description_handle_ismaster():2026 Topology description Unknown handling server description Mongos
[...]
[2020-11-10T14:54:53.587652+00:00] mongoc: TRACE > ENTRY: mongoc_topology_description_select():800
[2020-11-10T14:54:53.587726+00:00] mongoc: TRACE > TRACE: mongoc_topology_description_select():832 Topology type [Sharded], selected [Mongos] [localhost:4430]
[2020-11-10T14:54:53.587730+00:00] mongoc: TRACE > EXIT: mongoc_topology_description_select():835For what it's worth, I also tried moving the non-existent mongos to other places in the connection string, but that did not yield any issues.
If you are able to reproduce the problem, a trace like above would certainly be helpful. You can use ini_set('mongodb.debug', <target>); to either log to stdout or a log file. Before sharing such a log, be aware that the log could contain sensitive information, such as credentials or full documents. If you can reproduce this error with a ping command as done above, that would be ideal as this excludes most other causes. If not, please share a script that reproduces the error on your end along with the full debug log. Thank you!
H-Max
Alexander-L-G
Bug Report
When using a list of mongos processes in the connection string, connection fails if the first host is not available instead of failing over to other hosts.
Environment
PHP 7.4 in docker container Mongodb 4.4.1 sharded cluster (5 nodes, each a complete PSS replica-set) with 8+ mongos processes.
libbson bundled version => 1.17.0 libmongoc bundled version => 1.17.0 libmongoc SSL => enabled libmongoc SSL library => OpenSSL libmongoc crypto => enabled libmongoc crypto library => libcrypto libmongoc crypto system profile => disabled libmongoc SASL => enabled libmongoc ICU => disabled libmongoc compression => enabled libmongoc compression snappy => disabled libmongoc compression zlib => enabled libmongoc compression zstd => disabled libmongocrypt bundled version => 1.0.4 libmongocrypt crypto => enabled libmongocrypt crypto library => libcrypto mongodb.debug => no value => no value
Composer: name : mongodb/mongodb descrip. : MongoDB driver library keywords : database, driver, mongodb, persistence versions : * 1.7.0
Test Script
Initiate a client like that:
$client = new \MongoDB\Client("host1:33001,host2:33001,host3:33001");
Expected and Actual Behavior
The expected behavior, as described here is that if ever any of the hosts is down, it should try to connect to other ones. But it's not.
Instead, the connection fails as soon as we try a read with an error like that if host2 and host3 are down / unreachable (and host1 is OK) :
When trying with the mongo shell with this command, it works and connects to the mongos correctly:
I lookup at the serverSelectionTryOnce connection setting, but it does work and the documentation says: Multi-threaded drivers and mongos do not support serverSelectionTryOnce.
Can you please advise on that matter ? For now, I must explicitly specify only 1 mongos and this is a real issue.