vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Hallo Leute,


    ich habe seit 3 Tagen große Probleme mit meinem vServer.
    Vor ca. 3 Tagen habe ich ein Komplett-Backup über das VCP gemacht (ob es damit zusammenhängt oder Zufall ist, kann ich leider nicht sagen) und seitdem habe ich alle paar Stunden korrupte MySQL-Tabellen.


    Mir ist das ganze erst aufgefallen, als ich komischerweise längere Zeit keine eMails mehr bekommen. Via SSH konnte ich dann schnell erkennen, dass etliche postfix / smtpd - Prozesse noch liefen und anscheinend nicht fertig wurden.


    Im syslog fand ich dann auch schnell die Ursache:


    Code
    Nov 11 07:53:16 v230211191 postfix/smtpd[16536]: connect from mx0.gmx.net[213.165.64.100]
Nov 11 07:53:16 v230211191 postfix/trivial-rewrite[16539]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
Nov 11 07:53:16 v230211191 postfix/trivial-rewrite[16539]: fatal: mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf(0,lock|fold_fix): table lookup problem
Nov 11 07:53:17 v230211191 postfix/master[14028]: warning: process /usr/lib/postfix/trivial-rewrite pid 16539 exit status 1
Nov 11 07:53:17 v230211191 postfix/smtpd[16536]: warning: premature end-of-input on private/rewrite socket while reading input attribute name

    Aus irgendeinem Grund konnte postfix nicht mehr auf die MySQL-Tabellen zugreifen.
    Also startete ich MySQL neu und dann war das Problem tatsächlich behoben, weil MySQL beim Neustart wohl die korrupten Tabellen repariert hat.


    Allerdings dauerte es nur ~5 Stunden bis das ganze wieder anfing. So geht das nun schon seit 3 Tagen und ich kann die Ursache nicht finden.
    Ich habe sogar schon die syscp-Datenbank exportiert, gelöscht und wieder neu importiert.


    Nach dem Neustart von MySQL steht übrigens folgendes im syslog:

    Demnach sind wohl irgendwelche Tabellen nicht richtig "geschlossen" worden - was auch immer das heißt. Seltsam finde ich dabei, dass die syscp-Datenbank eigentlich nur MyISAM-Tabellen nutzt und gar keine InnoDB-Tabellen. Oder ist das mittlerweile das gleiche?


    An den Netcup-Support habe ich mich auch schon gewandt. Da hieß es nur, dass kein Speicher- oder Festplatten-Problem festgestellt werden konnte. Demnach muss es wohl irgendein Software-Problem sein.


    Zum Zeitpunkt als heute Morgen der Fehler zum ersten Mal aufgetreten ist (07:53) war der Server nur am idlen - abgesehen von den Syscp-Cronjobs. Kann es damit was zu tun haben?


    Noch ein paar technische Daten:
    vServer bronze
    Debian etch auf dem aktuellsten Stand
    Software wie bei Neuinstallation, lighttpd und denyhosts zusätzlich installiert


    Irgendwelche Ideen?


    Gruß
    Konni

    Hallo Konni,
    bezüglich InnoDB:
    Ich finde jetzt im Log keinen Hinweis darauf, daß die SysCP DB tatsächlich im InnoDB Format abgelegt wurde.


    Generell ist es bei einem Bronze Server vermutlich sinnvoll auf InnoDB zu verzichten, damit der Speicher nicht zu knapp wird. Hinweise zur deaktivierung von InnoDB finden sich hier im Forum.


    Prüfen kann man entweder in phpmyadmin. Dort steht für jede Tabelle der Typ gelistet, wenn man eine DB auswählt. Phpmyadmin ist auch gleich ein Ort an dem man komfortabel die Tabellen reparieren kann.


    Oder im Dateisystem typischerweise unter /var/lib/mysql
    Da findet sich je DB ein Unterverzeichnis in der je MyISAM Tabelle drei Dateien (*.MYD, *.MYI, *.frm) vorhanden sein sollten.



    Der syslog Fehler sagt lediglich aus, daß der Server nicht gefunden wurde, das heißt mysql wurde entweder nicht gestartet oder ist abgesemmelt. Steht dazu was in /var/log/mysql.log bzw. mysql.err ?


    Wieso wird der Server so häufig neu gestartet? Gibt es da eine Ursache?


    Was sagt "top" zur Speicherauslastung?

    Hallo Michi,


    danke schonmal für deine Antwort!


    Soweit ich weiß, nutze ich sowieso überhaupt keine InnoDB-Tabellen. Von daher hat mich ja auch irritiert, dass da in der Fehlermeldung etwas von InnoDB steht.


    Die Syscp-DB ist natürlich auch mit MyISAM-Tabellen.
    Ich schaue mal nach der Deaktivierung von InnoDB.


    Speichertechnisch ist der kleine Bronze-Server bei weitem nicht ausgelastet. Da ich ja den Apache in Rente geschickt habe und dafür der sparsame lighttpd läuft, liege ich in der Regel bei einer Auslastung von ca. 80 von 200 MB.


    Aktuell:

    Ausgabe von free:

    Code
    # free
             total       used       free     shared    buffers     cached
Mem:        204800      89512     115288          0          0          0
-/+ buffers/cache:      89512     115288
Swap:       409600          0     409600

    Die Fehlermeldung besagt zwar, dass der MySQL-Server nicht gefunden wurde, allerdings läuft dieser fehlerfrei. Ich kann problemlos mit phpmyadmin darauf zugreifen. Anscheinend hakt es nur bei den Tabellen, die dort im syslog auch als "ungeschlossen" vermerkt sind.


    Wenn ich den Server ja kurz neu starte, funktioniert ja wieder alles einwandfrei für eine gewisse Zeit lang.


    Die beiden MySQL-Logdateien sind komplett leer. Also entweder gibt es keine Einträge oder etwas stimmt nicht mit dem Logging.


    Wo habe ich geschrieben, dass ich den Server oft neu starte? Ich mache nur alle 6 bis 8 Wochen mal ein Komplett-Backup (Image) von dem kompletten System. Dazu muss ja leider der Server kurz heruntergefahren werden.


    Gruß
    Konni

    hallo Konni,

    meine syslog sah von gestern zu heut früh genauso aus.
    nach jeglichen neustarts das gleiche wie bei dir.


    nun läuft seit gegen 11 uhr alles wieder normal.
    Die Gründe dafür sind mir bis Dato noch rätselhaft.
    Da das Problem von allein kam und ging.
    es wurde nichts an den configs geändert.
    Zuvor lief der Server auch Tage ohne diese Einträge.

    Lg

    Zu den Fehlermeldungen. Ich sehe, daß der mysqld Neustart ziemlich genau auf 9:50 lief. Da kann es sein, daß der SysCP Cronjob (läuft normal genau alle 5 minuten) dazwischengefunkt hat und tatsächlich zwischen mysqld start und dem check durch "debian-start" die entsprechenden Tabellen gerade abgefragt hat.


    Das ist aber keine Antwort auf die andere Fehlermeldung. Dort wird ja ein Verbindungsfehler angezeigt. Selbst bei defekten Tabellen (mal abgesehen von den Tabellen in der mysql-db) wäre der Connect zunächst erfolgreich. Nur die Query würde dann mit entsprechender Fehlermeldung ggf. fehlschlagen.


    Ein häufiger Fehler für sporadisch fehlgeschlagene Verbindungen ist, daß die maximale Anzahl der gleichzeitigen Connects überschritten wurde. Die ist ggf. in /etc/mysql/my.cnf mit "max_connections" definiert.


    PhpMyAdmin gewährt dann ggf. noch den Zugriff, sofern man sich als ein User mit "SUPER privilege" anmeldet. Aber in der processlist sollten die Verbindungen evtl. noch zu sehen sein.


    Eine Überwachung von Diensten (postfix, mysql & co) bietet z.B. das Tool monit. Interessant bezüglich der max_connections ist da z.B. dieses:
    MySQL Event driven Process List

    Hallo Michi,


    in der my.cnf ist der Eintrag der max_connections auskommentiert. Gibt es in dem Fall gar keine Einschränkung oder wird einfach ein Standardwert genommen?


    Wenn dies wirklich das Problem gewesen wäre, frage ich mich, wo denn die vielen Connections hergekommen sein sollen. Ich bin der einzige Nutzer und verwendet wird der vServer eigentlich nur als komfortabler privater Webserver (IMAP + SMTP). Um die Uhrzeit habe ich noch im Bett gelegen ... ;)


    Nehmen wir mal an, es wären wirklich zu viele Connections gewesen:
    Hätte dann nicht nach einer Zeit (nachdem die Verbindungen getrennt gewesen wären) alles wieder einwandfrei funktionieren sollen? Stattdessen hatte ich ja die postfix-Einträge von ganz oben seitenweise im syslog. Das waren jede Minute 6 bis 7 Einträge.


    Kann ich die Anzahl der Verbindungen auch irgendwie schnell anzeigen lassen (ohne ein Monitoring-Tool zu installieren)? Kommandozeile oder phpmyadmin?


    Gruß
    Konni

    Wenn ich mich nicht Irre ist der Standartwert maximal 100 connections sofern nicht anders angegeben wird. Da das bei dir auskommentiert ist nutzt er den Standart wert von 100.


    Verbessert mich wenn ich da falsch liege.
    Ein Thread bezüglich Tipps zur Mysql Optimierung findest du übrigens hier
    http://forum.netcup.de/showthread.php?t=413&highlight=mysql


    MfG
    Andre

    Klar geht das mit den Connections auch in phpmyadmin.
    Auf der Startseite ist das der Link "Prozesse".


    Bei Deiner Nutzung ist das in der Tat relativ unwahrscheinlich, daß die Max-Connections erreicht wurden.

    Tja, ich hatte wohl doch kein Glück ...


    Seit heute Nacht sind die syslogs wieder voll von diesen Einträgen. Direkt nach dem Syscp-Cronjob um 3:00 Uhr ging's los ...


    MySQL rennt aber noch einwandfrei:
    # /etc/init.d/mysql status
    /usr/bin/mysqladmin Ver 8.41 Distrib 5.0.32, for pc-linux-gnu on x86_64
    Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
    This software comes with ABSOLUTELY NO WARRANTY. This is free software,
    and you are welcome to modify and redistribute it under the GPL license


    Server version 5.0.32-Debian_7etch11-log
    Protocol version 10
    Connection Localhost via UNIX socket
    UNIX socket /var/run/mysqld/mysqld.sock
    Uptime: 15 hours 21 min 27 sec


    Threads: 6 Questions: 1448 Slow queries: 0 Opens: 18 Flush tables: 1 Open tables: 12 Queries per second avg: 0.026.


    Nach einem Check in phpmyadmin sagt selbiges zu den Tabellen ftp_users und panel_settings:
    syscp.ftp_users check warning 2 clients are using or haven't closed the table pr...
    syscp.panel_settings check warning 2 clients are using or haven't closed the table pr...


    Ich weiß nicht mehr weiter ... :(



    Gruß
    Konni

    Nachtrag:
    Ich habe jetzt auch noch eine hohe Speicherauslastung, weil postfix wohl nicht die angestauten Mails verteilen konnte:



    Nach dem MySQL-Neustart wurden wohl auch diese Verbindungen getrennt:



    Ich habe eine Weiterleitung von einer GMX-Adresse zu einer Mail-Adresse auf dem vSever - daher wohl die vielen Verbindungen.


    Keiner einen Hinweis? Oder kennt jemand jemanden, der mir da helfen könnte (auch entgeltlich). Langsam nervt's nämlich ...


    Gruß
    Konni

    Hallo Konni,


    Also postfix meckert wieder, daß er keinen connect zu mysql bekommt? Oder von welchen Einträgen im Syslog sprichst Du?


    Die Prozessliste in phpmyadmin war leer? Wenn nein, was stand drin? Die Spalte "SQL-Befehl" wäre z.B. interessant.


    Ich habe momentan den Verdacht daß SysCP irgendwelche Tabellen sperrt und dann absemmelt und die locks stehen läßt. Wieso auch immer.


    Eventuell könnte man mal zwecks Test die cron-jobs für SysCP disablen (in etc/cron.d/syscp ein # vor die Zeilen setzen). Die Cron-Jobs müßten eigentlich (abgesehen von Statistiken) nur dann benötigt werden, wenn etwas geändert wurde.


    Die SysCP Cronjobs abzuschalten sollte natürlich kein Dauerzustand sein.



    In PhpMyadmin die syscp Tabellen "Reparieren".



    In /etc/php5/cli/conf.d evtl. mal die persistenten MySQL Verbindungen "disablen":
    Also folgende Zeile ändern (On zu Off):
    mysql.allow_persistent = Off


    Bei mir stehen in der Prozessliste regelmäßig ein paar Connections für SysCP auf "Sleep" herum, ich denke das sind obige "persistent links", da bei mir die Einstellung auf "On" steht.



    Bezüglich der "Remote Helping Hands" hatte der User Flo glaube ich mal was angeboten.

    Ja, genau - wieder die selben Fehlermeldungen wie in meinem ersten Beitrag.
    Also:

    Code
    Nov 12 03:04:33 v230211191 postfix/trivial-rewrite[4003]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
Nov 12 03:04:33 v230211191 postfix/trivial-rewrite[4003]: fatal: mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf(0,lock|fold_fix): table lookup problem
Nov 12 03:04:34 v230211191 postfix/master[15669]: warning: process /usr/lib/postfix/trivial-rewrite pid 4003 exit status 1
Nov 12 03:04:34 v230211191 postfix/smtpd[3999]: warning: premature end-of-input on private/rewrite socket while reading input attribute name
Nov 12 03:04:35 v230211191 postfix/trivial-rewrite[4004]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
Nov 12 03:04:35 v230211191 postfix/trivial-rewrite[4004]: fatal: mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf(0,lock|fold_fix): table lookup problem
Nov 12 03:04:36 v230211191 postfix/smtpd[3999]: warning: premature end-of-input on private/rewrite socket while reading input attribute name
Nov 12 03:04:36 v230211191 postfix/smtpd[3999]: warning: problem talking to service rewrite: Success
Nov 12 03:04:36 v230211191 postfix/master[15669]: warning: process /usr/lib/postfix/trivial-rewrite pid 4004 exit status 1
Nov 12 03:04:36 v230211191 postfix/master[15669]: warning: /usr/lib/postfix/trivial-rewrite: bad command startup -- throttling


    ... und so weiter.


    Die Prozessliste war nicht leer. Außer dem eigenen Prozess waren nur noch 5 oder 6 Einträge auf die Syscp-Tabelle vorhanden, allerdings auf "SLEEP" und ohne weitere Angaben in den anderen Feldern.


    Sowas in der Art (syscp-Cron-Job verursacht irgendwas) dachte ich mir auch schon. Zumal es ja immer nur die gleichen Tabellen anscheinend sind. Da ich aber so gut wie nie was ändere (1x im Monat vielleicht), werde ich den Cron-Job mal ausnehmen und dann mal weitersehen, wenn es jetzt tatsächlich fehlerfrei weiterläuft.


    Die persistenten Verbindungen werde ich dann mal abschalten, wenn das mit dem Cron-Job nicht hilft. Denn die sind ja sonst eigentlich schon sehr hilfreich. Wobei aber außer einem Webmailer so gut wie nichts auf dem Server installiert ist (php-technisch).


    Den Flo werde ich dann notfalls auch nochmal kontaktieren.


    Danke schonmal so weit! Schön, dass man hier schnell Hilfe bekommt!


    Schöne Grüße
    Konni

    Update:
    Auch der abgeschaltete Cron-Job hat nicht geholfen.


    Gestern Nacht habe ich noch bis kurz vor 3 Uhr gearbeitet. Da sieht man schön, wie ich mich um 2:56 Uhr aus meinem IMAP-Konto auslogge und direkt darauf fangen die Fehlermeldungen im syslog wieder an.


    Irgendwas ist da doch faul .... das lief doch jetzt über Monate einwandfrei ...


    Ich schalte jetzt noch die persistenten Verbindungen ab. Sonst weiß ich auch nicht mehr weiter.


    Laut syslog waren es dieses mal wieder die Tabellen "ftp_users" und "panel_settings".


    Gruß
    Konni

    Wenn die Verbindungen alle in Verwendung sind, dann schau doch mal, wer die hat. Vielleicht liegt der Fehler ja nicht an mysql sondern an "jemanden" der sich dorthin connectiert.


    Code
    netstat -nap


    Bebbo

    Zitat von sugersgroer;9339

    Hmm aufjedenfall sehr komisch


    hast denn darüber mal mit dem Support gesprochen? Vielleicht fällt denen ja noch was ein


    Mein erster Gedanke war ja ein defektes Dateisystem bzw. ein Speicherproblem. Diesbezüglich hatte ich ja den Support schon kontaktiert, der aber nichts feststellen konnte.


    Ich frage da auch nochmal nach.


    bebbo
    Wenn der Server morgen wieder abgeschmiert ist, werde ich mir die Ausgabe von netstat mal anschauen.


    Momentan läuft er wieder einwandfrei. Komischerweise schmiert er immer nur nachts / morgens ab, wenn eigentlich gar keiner drauf zugreifen sollte.


    Gruß
    Konni

    Wie zu erwarten war der Server heute morgen wieder in dem Zustand. Komischerweise ist den syslogs nach der Zeitpunkt wieder ca. 3 Uhr nachts gewesen. Zuvor scheint wohl mysql auch irgendwas gemacht zu haben.


    Hier der Ausschnitt:

    Ausgabe von netstat -nap hänge ich an.


    Kann da jemand Auffälligkeiten erkennen?


    Danke und viele Grüße
    Konni