Quelle est la bonne façon de contrôler les délais d'attente, du client, lors de l'exécution d'une base de données MySQL, en utilisant SQLALCHEMY? Le paramètre Je suis plus intéressé par ce qui se passe lorsque la machine est exécutée, par exemple, disparaît du réseau de manière inattendue. Je ne suis pas inquiet pour les requêtes elles-mêmes prenant trop de temps. P> Le script suivant fait ce que vous attendez (c.-à-d. Temps de temps après environ une seconde) si quelqueièmement em> est indisponible avant fort> le Il n'est pas surprenant que la variable de session connect_timeout code> URL semble insuffisant. code> La boucle est jamais atteinte. Mais si quelqueièrez em> baisse pendant strong> le tandis que code> boucle (par exemple, essayez de remonter son câble réseau après le démarrage de la boucle), alors le délai d'attente semble prendre au moins 18 secondes. Existe-t-il un paramètre supplémentaire ou un paramètre qui me manque? P> wait_timeout code> ne fonctionne pas, car je pense que c'est une variable côté serveur. Mais je l'ai jeté là-bas juste pour m'assurer. P> from sqlalchemy import *
from sqlalchemy.exc import *
import time
import sys
engine = create_engine("mysql://user:password@somehost/test?connect_timeout=1")
try:
engine.execute("set session wait_timeout = 1;")
while True:
t = time.time()
print t
engine.execute("show tables;")
except DBAPIError:
pass
finally:
print time.time() - t, "seconds to time out"
3 Réponses :
Cela pourrait-il être un bogue dans le connecteur MySQL / Python? https://bugs.Launchpad.net/myconny/+bug/328998 qui dit que le délai est codé dur à 10 secondes.
Pour vraiment voir où se trouve la panne, vous pouvez utiliser un sniffer de paquet pour vérifier la conversation entre le serveur et le client. Wireshark + TCPDump fonctionne bien pour ce genre de chose.
Je pense que vous atteignez une erreur totalement différente, une erreur "MySQL a disparu" redoutée, si je suis juste la solution consiste à mettre à jour un nouveau pilote mysqldb car le bogue a été des correctifs dans le pilote.
Si pour une raison quelconque, vous ne pouvez pas / ne vous mettre pas à jour, vous devez essayer la solution SA pour ce P>
db= create_engine('mysql://root@localhost/test', pool_recycle=True)
"MySQL est parti" des résultats lorsque le serveur MySQL déconnecte gracieusement au niveau TCP (I.E. FIN) mais anormalement au niveau de l'application. Cela ne contribuera donc pas à la détection d'un crash de serveur, car un serveur écrasé n'envoie aucune nageoire.
piscine_recycle prend un entier indiquant le nombre de secondes avant de recycler une connexion dans la piscine, pas une booléenne (peut-être qu'elle a fait en 2009, aucune idée)
Ce n'est pas possible grâce à la façon dont TCP fonctionne. Si l'autre ordinateur chute du réseau, cela cessera simplement de répondre aux paquets entrants. Les "18 secondes" que vous voyez sont quelque chose sur votre pile TCP chronométrant en raison d'aucune réponse.
La seule façon de faire que votre comportement souhaitée soit de générer un message "Je meurs" immédiatement avant qu'il ne meurt. qui, si la mort est inattendue, est complètement impossible.
Avez-vous déjà entendu parler d'entendeurs? Ce sont des paquets que les systèmes de haute disponibilité vous envoient chaque seconde ou moins pour laisser l'autre savoir qu'ils existent encore. Si vous souhaitez que votre application connaisse "immédiatement" que le serveur a disparu, vous devez d'abord décider de la durée "immédiate" (1 seconde, 200 ms, etc.), puis conçue un système (tel que des battements de coeur) pour détecter lorsque L'autre système n'est plus là.
C'est en fait l'une des choses que je me demandais; Si le protocole entre le client MySQL et le serveur comprenait une sorte de type de coeur périodique (par exemple, même si une longue requête se passait là-bas serait un battement de coeur périodique).
non, il n'y en a pas. Il existe un entre serveurs lors de l'utilisation de la version en cluster, mais pas entre le client et le serveur.
Accepter. Ceci essentiellement des jibs avec ce que je viens de lire efficacement TCP: Accueil.netcom.com/ ~ Jsnader / etcptoc.html
On dirait qu'il faut exister un délai d'attente de niveau de réseau associé à la prise que vous utilisez pour vous connecter au db ...
Pour avoir initié la connexion réseau, mais une fois la connexion établie, il apparaîtrait moins que vous puissiez faire. Cela semblerait être, en partie, en raison de la façon dont TCP est supposé travailler (par exemple, être assez tolérant des défaillances ou de longues périodes de communication inactive, etc.)
wait_timeout définit la durée combien de temps le client entre des commandes avant que le serveur MySQL ne décide de déposer la connexion.