MySQL startet von selbst neu?

  • Ich habe seit gestern Abend ein seltsames Problem: MySQL startet ohne Grund von selbst neu, das /etc/mysql/debian-start Script wird dabei aber nicht beachtet, somit hat Postfix danach kein gültiges MySQL-Socket mehr und mein Mailserver ist dann quasi offline. So habe ich das Problem überhaupt erst bemerkt.


    Ich habe alle Logs zum fraglichen Zeitpunkt kontrolliert, gefunden habe ich nur das:


    Zur selben Zeit scannte nur ein dummer Bot alles nach meinem PMA ab, hat er aber laut Logs nicht geschafft, da das Verzeichnis unter einer Subdomain läuft, doppelter Passwortschutz usw. besteht. Es gab auch sonst keine externen Zugriffe von Unbefugten, die das auslösen könnten.


    Im Log von meinem MySQL-Slave fand ich folgendes:

    Code
    Jan 28 09:01:48 <vserver2> mysqld[6251]: 100128  9:01:48 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)
    Jan 28 09:01:48 <vserver2> mysqld[6251]: 100128  9:01:48 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000339' position 38497103
    Jan 28 09:01:49 <vserver2> mysqld[6251]: 100128  9:01:49 [ERROR] Slave I/O thread: error reconnecting to master '<user>@<vserver1>:3306': Error: 'Lost connection to MySQL server at 'reading initial communication packet', system error: 111'  errno: 2013  retry-time: 60  retries: 86400
    Jan 28 09:02:49 <vserver2> mysqld[6251]: 100128  9:02:49 [Note] Slave: connected to master '<user>@<vserver1>:3306',replication resumed in log 'mysql-bin.000339' at position 38497103


    Das ganze geht nach einer Stunde wieder von vorne los. Das MySQL Bin-Log zeigt zu diesem Zeitpunkt nichts auffälliges, es wird nur ein Timestamp in einer Spalte aktualisiert. An der Serverkonfiguration habe ich in diesem Jahr noch nichts geändert, das habe ich durch Backups extra nochmals verglichen. Ich weiß nun echt nicht mehr wo ich den Fehler suchen soll, ich bin für jeden Denkanstoß dankbar!


    Im Moment läuft MySQL und Postfix wieder (nach einem manuellem Neustart von mysql und postfix), fragt sich allerdings wie lange :confused:



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Also an InnoDB kann es bei mir einmal nicht liegen, weil das ist komplett deaktiviert :D


    Zitat von Konni;12966

    Ich habe dann einfach eine Neuinstallation gemacht und jetzt läuft wieder alles einwandfrei.


    Dieser Schritt ist allerdings auch keine echte Lösung, denn die Ursache behebt es damit ja auch nicht :o



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Zitat von [netcup] Felix;12969

    Das Phänomen deutet auf defekte Tabellen hin. Einfach mal loggen lassen und die defekten Tabellen versuchen zu reparieren.


    In den Logs finde ich darüber eben nichts. Und zur Sicherheit habe ich bereits gestern Abend alle Tabellen aller DB's überprüfen und reparieren lassen :o



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich hatte ja auch alles wochenlang überwacht, Logs gewälzt, verschiedene Konfigurationen ausprobiert, etc.


    Ich habe sogar alle Datenbanken gelöscht und neu importiert. Ich habe wirklich alles ausprobiert, was irgendwie nur annähernd sinnvoll war. Letztendlich war ich es leid und habe die Nutzdaten gesichert und das System neu aufgesetzt. Seitdem ist Ruhe.


    Gruß
    Konni

  • Also seit damals gab es jetzt keine Probleme mehr, geändert habe ich allerdings nichts mehr, nur Logs in Echtzeit beobachtet. Heute kam auch ein Update für MySQL bei Lenny heraus, vielleicht behebt das dann eventuelle Fehler. Wie auch immer, ich werde es beobachten. Trotzdem danke für eure Tipps :)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Zu früh gefreut, seit gestern 19 Uhr spinnt es wieder :rolleyes:
    Bis ich den Fehler gefunden habe, vorerst diese Lösung als Daemon-Script :D
    [PHP]#!/usr/bin/php
    <?php


    // MySQL Problem - siehe http://forum.netcup.de/showthread.php?t=1492
    // Durchsucht das Syslog andauernd, ob das Problem wieder aufgetreten ist,
    // falls ja wird das MySQL Socket neu gelinkt und den Fehler zu umgehen.
    $pattern = 'Number of processes running now: 0';
    $syslog = '/var/log/syslog';
    $email = 'admin@froonix.com';


    if(posix_getuid() !== 0)
    {
    trigger_error('You are not root', E_USER_ERROR);
    }


    // Pipes vorbereiten
    $desc = array(
    // 0 => array('pipe', 'r'), // STDIN ist eine Pipe, von der das Child liest
    1 => array('pipe', 'w'), // STDOUT ist eine Pipe, in die das Child schreibt
    );


    // Los geht's
    // $proc = proc_open('tail -f ' . escapeshellarg($syslog) . ' | grep '.escapeshellarg($pattern), $desc, $pipes);
    // $proc = proc_open('tail -n 1000 -f ' . escapeshellarg($syslog) . ' | grep '.escapeshellarg($pattern), $desc, $pipes);
    $proc = proc_open('tail -f ' . escapeshellarg($syslog), $desc, $pipes);
    if(!is_resource($proc))
    {
    trigger_error('Can\'t start log detection', E_USER_ERROR);
    }
    else
    {
    // Damit die Pipes auch wieder geschlossen werden ;)
    register_shutdown_function('close_pipes');

    // Und verändern den Modus
    // stream_set_blocking($pipes[0], 0);
    stream_set_blocking($pipes[1], 0);
    }


    // Wir starten unsere Endlosschleife *gg*
    $proc_get_status = 0;
    while(true)
    {
    // Dann versuchen wir einmal etwas einzulesen
    $line = fgets($pipes[1]);
    if($line === false || $line === '' || is_null($line))
    {
    // Lebt unser Child noch?
    if($proc_get_status < (time() - 10))
    {
    if(!($tmp = proc_get_status($proc)) || !$tmp['running'])
    {
    trigger_error('Child terminated', E_USER_ERROR);
    }
    else
    {
    $proc_get_status = time();
    }
    }

    // Zur Zeit gibt es wohl nichts zum Lesen
    usleep(1000 * 1000);
    continue;
    }
    elseif(strpos($line, $pattern) !== false)
    {
    // Debug
    // echo '...'."\n";

    // Link neu erstellen
    @unlink('/var/spool/postfix/var/run/mysqld/mysqld.sock');
    exec('ln /var/run/mysqld/mysqld.sock /var/spool/postfix/var/run/mysqld/mysqld.sock');

    // Postfix neu starten
    exec('/etc/init.d/postfix restart');

    // Loggen und ausgeben
    syslog(LOG_CRIT, 'Linking mysqld.sock to the postfix-jail and restarting postfix!');
    echo 'Linking mysqld.sock to the postfix-jail and restarting postfix!'."\n";

    // Mail versenden
    mail($email, 'MySQL Problem Report', 'Linking mysqld.sock to the postfix-jail and restarting postfix!');

    // Zur Sicherheit hier auch etwas warten
    sleep(30);
    }
    }


    // Pipes am Ende wieder schließen
    function close_pipes()
    {
    global $pipes;

    // fclose($pipes[0]);
    fclose($pipes[1]);
    }


    ?>[/PHP]


    Und zum Testen recht nett :D

    Code
    php -r "var_dump(syslog(7, 'Number of processes running now: 0'));"



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Bei mir war ja das Problem schon unter Etch vorhanden und auch nach Upgrade auf Lenny noch präsent. Anfangs war es auch nur alle paar Tage, dann täglich und manchmal sogar mehrfach täglich.


    Jetzt nach der Neuinstallation ist alles fein. Und ich hoffe, das bleibt auch so.


    Gruß
    Konni

  • Hmmm, egal was ich versuche, nichts bringt etwas. Noch irgendwelche kreativen Vorschläge, an was es liegen könnte? :(
    Defekte Tabellen sind es nicht, am Slave liegt es auch nicht. Tageweise schon mal deaktiviert und komplett neu gesynct.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Seit gestern spinnt es nun komplett. Alle 15 Minuten Neustart und nach einiger Zeit beendete er sich dann ganz:

    Zitat

    Feb 27 12:50:18 ***** mysqld_safe[17647]: Number of processes running now: 0
    Feb 27 12:50:18 ***** mysqld_safe[17649]: restarted
    Feb 27 12:50:19 ***** mysqld_safe[17711]: ended


    Die Replikation kann ich mittlerweile ganz ausschließen, die hatte ich testweise schon ganz deaktiviert. Ich werde heute Nacht eine Neuinstallation von MySQL versuchen, wenn das auch nichts hilft weiß ich auch nicht mehr weiter...


    Update: mysqldump und/oder Tabellen optimieren kann diese Probleme aber nicht rein zufällig auslösen?
    Mir kommt da ein seltsamer Verdacht, dass es vielleicht in Zusammenhang mit dem Backup-Script steht.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Bei mysqldump würde ich sagen: nein


    Im unwahrscheinlichen Falle des Einsatzes von mysqlcheck könnte das schon sein. Dessen Anwendung sollte aber auch nicht der Regelfall sein, zumal es nur auf MyIsam anwendbar ist.


    Hast Du denn bereits herausgefunden wobei MySQL absemmelt? Ggf. kann man ja die Cronjobs mal für eine Weile aussperren.


    Zur Socket/Neustartproblematik hast Du Dir ja schon etwas gebastelt. Ansonsten wäre ggf. eine Postfix-Config mit Zugriff über localhost/127.0.0.1 eine temporäre Alternative?


    Hast Du das General Query Log aktiviert? Was passiert, bevor MySQL absemmelt?

  • Zitat von michi;14523

    Hast Du denn bereits herausgefunden wobei MySQL absemmelt? Ggf. kann man ja die Cronjobs mal für eine Weile aussperren.


    Leider nicht, ich stehe noch immer bei Null.


    Zitat von michi;14523

    Zur Socket/Neustartproblematik hast Du Dir ja schon etwas gebastelt.


    Naja, seit der gestrigen Problematik, dass MySQL irgendwann komplett weg war und manuell neu gestartet werden muss, bringt das scheinbar auch nichts mehr.


    Zitat von michi;14523

    Ansonsten wäre ggf. eine Postfix-Config mit Zugriff über localhost/127.0.0.1 eine temporäre Alternative?


    Ja, habe ich jetzt temporär auch einmal umgesetzt. Bringt leider auch nichts, wenn MySQL wieder einmal ganz weg ist :D


    Zitat von michi;14523

    Hast Du das General Query Log aktiviert? Was passiert, bevor MySQL absemmelt?


    Bisher nicht, jetzt ist es einmal aktiviert. Im Bin-Log stand jedenfalls nichts auffälliges, aber das wird ja erst nach der erfolgreichen Beendigung eines Queries geschrieben. Das hatte ich irgendwie vergessen :o



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Gleiches Problem.
    Vorgestern bzw. gestern startete mein MySQL auch immer neu. Mal neu, mal musste ich ihn manuell restarten. Habe dann alle Tabellen repariert & optimiert.


    Jetzt läuft er seit gestern morgen....

  • Damit ich die Ausfälle schneller mitbekomme (wenn MySQL z.B. wieder ganz weg ist) habe ich mir jetzt ein Script erstellt, dass es separat loggt und mir eine SMS sendet, sobald wieder der selbe MySQL-Eintrag im Syslog vorhanden ist. Natürlich mit einer Interval-Sperre von einer Stunde, sonst wird's teuer, wenn MySQL andauernd abstürzen sollte :D



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Gerade ist MySQL wieder abgestürzt und wurde neu gestartet. Im mysql.log steht als letzter Eintrag ein ganz normaler Query, wie er jede Minute genau so ausgeführt wird (nur ein anderer Timestamp darin). Im Bin-Log ist dieser Query allerdings nicht mehr vorhanden, was eindeutig bestätigt, dass dieser Query irgendwie alles zum Absturz brachte. Nur wie ist absolut unklar. Der Query führte so nirgends zum Fehler. Auch durch ein direktes Ausführen des Queries kann der Absturz nicht reproduziert werden.


    Ich stehe also wieder bei Null...


    [offtopic]
    Und wieder was vergessen: Für Logdateien braucht man tail -F --max-unchanged-stats=5 <file>
    Und ich wunder mich, warum die SMS-Benachrichtigung heute Abend nicht funktionierte :rolleyes:
    [/offtopic]



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Irgendwelche kreativen Ideen noch? Wie gesagt, ich stehe wieder bei Null :o



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)