Beitrag wurde zuletzt am aktualisiert

MySQL-Problem ‚mysqladmin flush-hosts‘

MySQLadmin Flush HostsMySQLadmin Flush Hosts

Plötzlich wird der Besucher einer Website mit der folgenden Fehlermeldung begrüßt:

Warning: mysql_connect()
[function.mysql-connect]: Host ‚hostname‘ is blocked because of many connection errors; unblock with ‚mysqladmin flush-hosts‘ in /home/www/example-path/includes/example-script.php on line 42
Keine Verbindung möglich!

Man findet bei der Suche nach dieser Fehlermeldung eine ganze Reihe Websites, die von Google genau in der Zeit gecrawlt wurden, als es zur MySQL-Connect Fehlermeldung kam. Diese Inhalte wurden teilweise auch indexiert, sodass Websites, die sich eigentlich nicht mit Datenbank-Problematiken befassen, sich trotzdem in den Google Top 100 zu entsprechenden Suchanfragen wiederfinden.
Je nach Überwachungsintervall einer Seite kann dies bei stiefmütterlich behandelten Projekten auch mal schnell mehrere Tage dauern, bis irgendwer auf diesen Fehler aufmerksam wird.

Die Lösung für dieses Problem steht ja eigentlich schon direkt in der Fehlermeldung.

Der Aufruf von mysqladmin mit dem Parameter flush-hosts auf dem MySQL-Server kann und wird weiter helfen. Vorausgesetzt man selbst Zugriff als root auf den Server. Wer diese Möglichkeit nicht besitzt, dem bleibt nur noch sich mit seinem Hoster in Verbindung zu setzen, sodass dieser sich 1 Minute Zeit nimmt und das Problem (erst mal) behebt.

Der Konsolenbefehl: mysqladmin flush-hosts

Als erstes auf den Server anmelden und hier den bereits in der Fehlermeldung erwähnten Aufruf als root bzw. via sudo absetzen.

mysqladmin flush-hosts

Der Spuk ist damit vorerst vorbei, wie ein erneuter Aufruf der eben noch fehlerhaften Website zeigt. Doch zurück lehnen hilft nur bis zur nächsten Meldung dieser Art, was je nach Auslöser bereits nach wenigen Sekunden der Fall sein kann.

Anpassung der MySQL-Konfiguration

Um etwas länger vor manuellen Eingriffen des Admins – und somit vor Ausfällen der Website – verschont zu bleiben, verspricht ein Eintrag in die my.cnf, der Konfigurationsdatei von MySQL, Abhilfe.

mcedit /etc/mysql/my.cnf

Hier lässt sich im Bereich [mysqld] mit folgender zusätzlichen Zeile der Standardwert für Verbindungsfehler von 10 auf einen praktisch beliebigen Wert anheben.

max_connect_errors = 100

Abspeichern und nach einem Restart von MySQL würde nun erst nach 100 fehlerhaften Verbindungen der entsprechende Host gesperrt werden (das geht natürlich auch mit einem Wert von 1.000, 10.000 oder noch höher). Nur die in MySQL eingebaute Begrenzung ist hier ja nicht zum Spaß Bestandteil der Software! Hiermit lassen sich natürlich Hacker-Attacken verhindern oder man wird auf Netzwerkfehler aufmerksam gemacht.
Vielleicht hat man aber auch ein Script am Laufen, was sich immer wieder fehlerhaft versucht auf den MySQL-Server zu verbinden. Hier kann man nur in der MySQL-Prozessliste suchen und das Problem versuchen auf diese Art lokalisieren.

Alternativen zur Bearbeitung der my.cnf

In irgendeinem Forum habe ich gelesen, dass man sich einen entsprechenden Cronjob einrichten könnte, der dann pauschal alle 5 Minuten (oder einer anderen Zeitspanne) ein „flush-hosts“ durchführt.

crontab -e
*/5 * * * * mysqladmin flush-hosts

Nun ja, dann könnte man auch gleich den MySQL-Dienst permanent neu starten, Daumendrücken oder einfach auf besseres Wetter hoffen. Also bitte nicht nachmachen!

In der MySQL-Dokumentation findet man auch noch eine weitere Lösung, um den Wert für die maximalen Verbindungsfehler zu erhöhen. Hier wird auf das Shellscript mysqld_safe näher eingegangen. Wer seine my.cnf nicht anfassen möchte, ist hiermit gut beraten.

Bildnachweis Logo: www.mysql.de

2 Kommentare zu "MySQL-Problem ‚mysqladmin flush-hosts‘"

  1. Für das Problem such ich auch eine Lösung. Umgebung ist Typo3, Mysql, Apache, alles unter Linux RH. Ich beschäftige mich schon einige Zeit damit für das Problem eine Lösung zu finden. Auf den unten aufgeführten Seiten werden mehrer Gründe angegeben die diesen Fehler auslösen könnten.

    Mir ist aufgefallen das Typo3 Blob Datentypen verwendet. Ich habe in einer Tabelle, sys_log von Typo3, mehrere Zeile gefunden die mehrere Seiten lang sind und vermute daher das das Problem mit max_allowed_packet gelöst werden könnte wenn der Wert vergrössert wird.

    http://dev.mysql.com/doc/refman/5.0/en/communication-errors.html
    http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html

    Leider habe ich keine Informationen auf den Seiten zu Typo3 gefunden die Anforderungen bezüglich der Konfiguration von Mysql zum Datentyp Blob beschreiben.

    Mit flush hosts oder grösseren Wert für max_connect_error ist das Problem nicht gelöst, das ist maximal ein Workaround.

    Suchen wir weiter nach Fehler in Software und nach deren Lösung. Das scheint ja weltweit akzeptanz zu haben und sich zu einem Volkssport zu entwickeln. Warum man für Software noch Geld bezahlen muss wenn man Fehler findet ist mir schleierhaft. Geisiges Eigentum von wem ? von denen die unbezahlt Zeit aufwenden milliarden schwere Konzerne deren Fehler zu zeigen ? Wenn jemand sich ein Auto kaufen würde das keine Bremsen hat was würde da wohl passieren … Softpears ? Automatisches Update ?
    gatesnoch ?

  2. Zitat: „Suchen wir weiter nach Fehler in Software und nach deren Lösung. Das scheint ja weltweit akzeptanz zu haben und sich zu einem Volkssport zu entwickeln. Warum man für Software noch Geld bezahlen muss wenn man Fehler findet ist mir schleierhaft. Geisiges Eigentum von wem ? von denen die unbezahlt Zeit aufwenden milliarden schwere Konzerne deren Fehler zu zeigen ? Wenn jemand sich ein Auto kaufen würde das keine Bremsen hat was würde da wohl passieren … Softpears ? Automatisches Update ?
    gatesnoch ?“

    Dem kann ich nur zustimmen!! Da ist ein Error im Denken der Gesellschaft. Alles wird immer neu gemacht und doch ist es nicht wirklich besser.

Hinterlasse einen Kommentar

E-Mail Adresse wird nicht veröffentlicht.


*