9
votes

Mise à niveau vers PYMONGO 3.0 résultant de SERVERSELYSTELTTIRORROR

J'ai récemment mis à niveau une bouteille + UWSGI + NGINX Application à MongoDB 3.0.2. Cela fonctionnait bien avec PymonGo 2.8, mais aujourd'hui, j'ai mis à jour à PymonGo 3.0 en exécutant la commande suivante:

>>> import pymongo
>>> host = "localhost"
>>> port = 27017
>>> connection = pymongo.MongoClient(host=host, port=port)
>>> db = connection[test]
>>> db.test.insert_one({"test": True});
<pymongo.results.InsertOneResult object at 0x7fc43b8efc80>


3 commentaires

Je n'ai pas de réponse pour vous, sauf que si vous pouvez vous connecter avec une coque Python, mais pas de votre application, c'est vraiment étrange et suggère que ce n'est pas une question de pilote. Votre configuration me semble bien, elle devrait fonctionner la même chose à PymonGo 2.8 et 3.0. Je vais garder un oeil sur cette question.


Merci. J'ai rétrogradé à Pymongo 2.8 pour le moment, mais je vais essayer à nouveau.


@Juancarlosfarah Merci pour le pointeur - j'ai également rétrogradé à 2,8 et corrigé mon problème. Toute nouvelle sur une meilleure solution?


5 Réponses :


-1
votes

pourrait-il être lié à Ce bug Pymomongo 3.0 critique lors de l'utilisation de Mongos? Si tel est le cas, ils ont poussé une solution sur la branche principale (voir Ce commit . )


2 commentaires

Non pertinent. Ce bogue ne manifeste que lorsqu'il y a plusieurs noms d'hôte dans sa chaîne de connexion; Il utilise juste un nom d'hôte. En outre, le symptôme est l'opérationFAILURE, pas des serversTimeSeutrorRor.


Je n'utilise pas de Mongos , de sorte que cela ne serait pas lié à cela.



-1
votes

édité:

Avez-vous vérifié votre fichier journal de MongoDB? Je pense que j'avais le même problème que toi.

J'ai trouvé le problème suivant dans / var / log / mongodb: xxx

dans le poste suivant est la solution pour cette erreur: Pourquoi faire de l'erreur Mongod Morte mais sous-sols verrouillé et insuffisant de l'espace libre pour les fichiers de journal sur Linux?

Il semble que mon problème soit résolu. Peut-être avez-vous la même erreur et vous devez utiliser des petits feux afin de travailler.

Cordialement Cordialement.


0 commentaires

0
votes

Le correctif pour moi était surprenant; je suis entré à l'invite de bash : xxx

crédit à Cette réponse . Il s'est avéré être un problème d'autorisations Apache.


Remarque: Je cours Pymongo 3.0, Python 2.6 et Mongo 2.4 sur Centos 6.6. J'ai eu une erreur marginalement différente, mais c'était dans la même ligne de Pymongo. C'était la fin de ma trace de la pile: xxx


1 commentaires

Cela n'a pas fonctionné pour moi (même erreur que OP). J'ai également constaté que la dégradation de 2,8 fixe le problème.



1
votes

Il semble être le même problème que dans Cette question , et Ce Bug . Cependant, j'ai essayé de définir Connect = False dans la création de Mongoclient () comme suggéré à rien en vain. Actuellement, la seule solution qui semble fonctionner à travers la carte est de rétrograder à 2,8 ( PIP INSTALL PYMONGO == 2.8 )


0 commentaires

0
votes

Je pense que c'est un duplicata de ce Question .

La solution de contournement pour éviter de déclencher le bogue fonctionne bien (Pass Connect = False lors de la création d'instances de Mongoclient). Il y aura un avertissement plus clair dans la version 3.0.4 de Pymongo. et espérons-le une solution dans les versions suivantes.


0 commentaires