Beiträge von Konni

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

    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

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

    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

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

    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

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

    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

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

    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

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

    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

  • 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