MySQLdb-Ausführungszeitüberschreitung

Question

Manchmal tritt in unserer Produktionsumgebung eine Situation auf, in der die Verbindung zwischen dem Dienst (der ein Python-Programm ist, das MySQLdb verwendet) und dem MySQL-Server fehlerhaft ist, einige Pakete verloren gehen, etwas schwarze Magie passiert und .execute() des MySQLdb.Cursor-Objekts nie endet (oder sehr viel Zeit zum Beenden benötigt).

Dies ist sehr schlecht, weil es eine Verschwendung von Service-Worker-Threads ist. Manchmal führt es zur Erschöpfung des Worker-Pools und der Dienst reagiert überhaupt nicht mehr.

Die Frage ist also: Gibt es eine Möglichkeit, die Operation MySQLdb.Connection.execute nach einer bestimmten Zeit zu unterbrechen?

Answer 1

Wenn die Kommunikation ein solches Problem darstellt, sollten Sie einen "Proxy" schreiben, der Ihre SQL-Befehle über die unzuverlässige Verbindung empfängt und sie über einen zuverlässigen Kanal an den MySQL-Server weiterleitet (der vielleicht auf demselben Rechner wie der MySQL-Server läuft). Auf diese Weise haben Sie die volle Kontrolle über die Fehlererkennung und die Wiederholungsversuche.

Answer 2

Sie müssen genau analysieren, worin das Problem besteht. MySQL-Verbindungen sollten irgendwann einen Timeout haben, wenn der Server nicht mehr erreichbar ist; TCP-Keepalives sind in der Regel aktiviert. Möglicherweise können Sie die TCP-Timeouts auf Betriebssystemebene einstellen.

Wenn die Datenbank "unzuverlässig" ist, müssen Sie auf jeden Fall herausfinden, wie. Es scheint unwahrscheinlich, dass die Datenbank wirklich das Problem ist, wahrscheinlicher ist, dass das Netzwerk dazwischen liegt.

Wenn Sie (einige) zustandsbehaftete Firewalls verwenden, ist es möglich, dass diese einen Teil des Zustands verlieren, was dazu führt, dass ansonsten gute, langlebige Verbindungen unterbrochen werden.

Sie sollten in Erwägung ziehen, den Idle-Timeout-Parameter in MySQL zu ändern; andernfalls kann eine langlebige, ungenutzte Verbindung "veralten", so dass sowohl der Server als auch der Client denken, sie sei noch aktiv, aber irgendein zustandsabhängiges Netzwerkelement dazwischen hat die TCP-Verbindung "vergessen". Eine Anwendung, die versucht, eine solche "veraltete" Verbindung zu benutzen, wird lange warten müssen, bevor sie eine Fehlermeldung erhält (aber das sollte sie schließlich).