Vous rencontrez des difficultés pour vous connecter aux ensembles d'instances dupliquées MongoDB après la mise à niveau du pilote Ruby MongoDB vers la version 2.5.x ? Nous avons récemment reçu quelques demandes de renseignements concernant ce problème avec la dernière version du pilote MongoDB Ruby et avons rédigé ce message pour partager nos conclusions sur le problème et sa cause.

Le message d'erreur rencontré lors de la tentative de connexion était -

No server is available matching preference: #<Mongo::ServerSelector::Primary:...>

Le problème a déjà été signalé à MongoDB et est suivi ici. Nous avons passé un peu de temps à étudier ce problème et la cause première introduite dans le code du pilote dans la version 2.5.x.

Résumé du problème du pilote MongoDB Ruby 2.5.x

Le problème existe dans la ou les versions 2.5.x du pilote MongoDB Ruby et se produit lorsque les noms d'hôte comprenant le jeu de réplicas contiennent des caractères sensibles à la casse, par exemple, ABC-server1.example.com . Les solutions de contournement possibles sont :

1.  Retrogradez vers la version 2.4.x ou mettez à niveau la version 2.6.x dès qu'elle sera disponible.
2. Modifiez les noms d'hôte de tous les membres des jeux de réplicas en minuscules. Par exemple, remplacez le nom d'hôte dans l'exemple ci-dessus par abc-server1.example.com.

Détails sur le problème

L'activation de la journalisation détaillée sur Ruby a fourni un indice sur ce qui se passait :

...
#19140] DEBUG -- : MONGODB | Topology type 'replica set' initializing.
#19140] DEBUG -- : MONGODB | Server sg-connectiontest1-13622.servers.example.com:27017 initializing.
#19140] DEBUG -- : MONGODB | Server description for sg-connectiontest1-2.servers.example.com:27017 changed from 'unknown' to 'unknown'.
#19140] DEBUG -- : MONGODB | Server sg-connectiontest1-13623.servers.example.com:27017 initializing.
#19140] DEBUG -- : MONGODB | Server description for sg-connectiontest1-3.servers.example.com:27017 changed from 'unknown' to 'secondary'.
#19140] DEBUG -- : MONGODB | Server sg-connectiontest1-13624.servers.example.com:27017 initializing.
#19140] DEBUG -- : MONGODB | Server description for sg-connectiontest1-4.servers.example.com:27017 changed from 'unknown' to 'arbiter'.
#19140] DEBUG -- : MONGODB | There was a change in the members of the 'replica set' topology.
C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/mongo-2.5.1/lib/mongo/server_selector/selectable.rb:119:in `select_server': No server is available matching preference: # using server_selection_timeout=30 and local_threshold=0.015 (Mongo::Error::NoServerAvailable)
from lib/ruby/gems/2.4.0/gems/mongo-2.5.1/lib/mongo/database.rb:157:in `command'
from lib/ruby/gems/2.4.0/gems/mongo-2.5.1/lib/mongo/client.rb:404:in `list_databases'
from lib/ruby/gems/2.4.0/gems/mongo-2.5.1/lib/mongo/client.rb:385:in `database_names'
...

Il semblait évident que le pilote n'était pas capable de détecter correctement le rôle du primaire du jeu de répliques. Lors de la comparaison avec les journaux de la version 2.4.x, il était clair que cela se produisait correctement sur cette version, c'est-à-dire que le principal était correctement identifié comme le principal.

] DEBUG -- : MONGODB | Topology type 'replica set' initializing.
] DEBUG -- : MONGODB | Server sg-connectiontest1-13622.servers.example.com:27017 initializing.
] DEBUG -- : MONGODB | Server description for sg-connectiontest1-2.servers.example.com:27017 changed from 'unknown' to 'primary'.
] DEBUG -- : MONGODB | Server sg-connectiontest1-13623.servers.example.com:27017 initializing.
] DEBUG -- : MONGODB | Server description for sg-connectiontest1-3.servers.example.com:27017 changed from 'unknown' to 'secondary'.
] DEBUG -- : MONGODB | Server sg-connectiontest1-13624.servers.example.com:27017 initializing.
] DEBUG -- : MONGODB | Server description for sg-connectiontest1-4.servers.example.com:27017 changed from 'unknown' to 'arbiter'.

L'autre indice que nous avions était que les noms de nos serveurs avaient été légèrement modifiés dans les journaux. Au lieu du vrai nom SG -connectiontest1-2.servers.example.com , il était enregistré en tant que sg -connectiontest1-2.servers.example.com .

En inspectant le code sur la façon dont les noms d'hôte sont analysés lors de l'initialisation de la connexion et les rôles qui leur sont attribués, nous avons pu déterminer que le code du pilote était en casse (c'est-à-dire qu'il convertissait ABC. example.com à abc.example.com) lors de l'analyse de la chaîne de connexion. Ensuite, le pilote se connecte au primaire pour découvrir la topologie à l'aide de la commande isMaster. C'est en parsant le résultat de cette commande que le pilote détermine le rôle de chaque nœud.

Cependant, lors de la comparaison des noms d'hôte renvoyés par la commande avec ceux de la chaîne de connexion, le pilote ignorait d'effectuer une correspondance insensible à la casse. Cela a conduit à une incompatibilité dans les noms du primaire, comme indiqué par MongoDB, par rapport à ce que le pilote avait déterminé à partir de la chaîne de connexion. Cela a rendu le rôle du principal inconnu et a conduit à l'échec de la connexion. La vérification de correspondance d'adresse dans le code de détection de rôle a été ajoutée dans la version 2.5.x.

Le correctif du problème a été ciblé sur la version 2.6.0 du pilote.