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

  • hmm also aus dem log entnehme ich das definitiv der cron der auslöser vom crash ist. denn das is das letzte da schmierte mysql ab start in den safe mode startet dann neu und führt die crash recovery aus danach läufts ja wieder normal.


    Ich hab leider kein syscp bei mir drauf aber ich werd auf dem testserver mal etch mit syscp aufspielen.


    vom fertigen image bis jetz bräucht ich dann mal ne detailierte liste was genau du geupdated hast und welche einträge du in der sources list hast das ich den fehler nachstellen kann.
    Und wenn ich den Fehler nicht bekomme is bei dir doch schon irgendwas anderes faul ^^


    Der cron killt alle php prozesse die die maxlifetime überschritten oder erreicht haben soweit ich das grad so sehe


    MfG
    Andre

  • Ich muss jetzt noch kurz an die Uni, danach gibt es die nötigen Infos.


    Zusätzlich sind glaube ich nur denyhosts und lighttpd installiert (via apt-get). Alle Programme sind mittels dist-upgrade auf den neuesten Stand gebracht worden. sources.list ist noch die originale, kann ich aber dann gerne nochmal hier einfügen.


    Danke und Gruß
    Konni


    PS: Alternativ würde ich auch einfach eine Neu-Installation durchführen - dann aber am liebsten schon gleich mit Lenny.

  • Oki dann wart ick mal auf die infos ;) lass dir zeit muß auch demnächst eh erstmal zur arbeit aber denke mal so entweder heut nachmittag/abend spätestens jedoch heut nacht hab ich das dann testen können



    MfG
    Andre

  • Zitat von sugersgroer;9459

    Der cron killt alle php prozesse die die maxlifetime überschritten oder erreicht haben soweit ich das grad so sehe


    Falsch, dieser Cronjob löscht alle alten PHP-Sessions ;)

    PHP
    # /etc/cron.d/php5: crontab fragment for php5
    #  This purges session files older than X, where X is defined in seconds
    #  as the largest value of session.gc_maxlifetime from all your php.ini
    #  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime
    
    
    
    
    # Look for and purge old sessions every 30 minutes



    MfG Christian

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

  • Ich glaube auch nicht, dass es an dem PHP-Cron liegt, da der ja alle 30 Minuten einwandfrei durchläuft. Warum sollte er gerade nachts immer einmal zu einem Problem mit postfix und MySQL führen.


    Im Anhang habe ich noch meine sources.list + eine packages.list, die alle installierten Pakete und Programme enthält.


    Ich kann auch gerne mal root-Zugriff jemandem geben, wenn es jemanden mit sehr guten Debugging-Kenntnissen gibt.


    Gruß
    Konni

  • Kleiner Nachtrag:
    Was ich auch sehr seltsam finde, ist, dass MySQL gar nichts loggt. Sowohl mysql.log wie auch mysql.err sind komplett leer (0 Byte).


    Ist da nicht standardmäßig ein Logging aktiviert? Ich schaue mal in die Config ...


    Edit: Ich habe jetzt das Logging mal testweise aktiviert (schluckt laut der Kommentare wohl ordentlich Performance).


    Gruß
    Konni

  • Hallo Konni,


    falls dein postfix bzw. Teile davon tatsächlich chrooted laufen, dann solltest du dir mal die Doku zu proxymap anschauen. Die Anleitung mit dem Link ist meiner Meinung nach eher unschön, falls sie denn überhaupt funktionieren sollte.


    In jedem Fall sollten postfix und andere Dienste deinen mysql server nicht zum crashen bringen können. Falls du noch nicht sichergestellt hast, dass alle Dienste nicht mehr Arbeitsspeicher wollen können als dir zur Verfügung steht, d.h. im Wesentlichen jeweils die maximale Anzahl an Prozessen beschränkt hast, solltest du das mal tun und dann den mysql server komplett neu aufsetzen.

  • Zitat von henk77;9493

    Hallo Konni,


    falls dein postfix bzw. Teile davon tatsächlich chrooted laufen, dann solltest du dir mal die Doku zu proxymap anschauen. Die Anleitung mit dem Link ist meiner Meinung nach eher unschön, falls sie denn überhaupt funktionieren sollte.


    In jedem Fall sollten postfix und andere Dienste deinen mysql server nicht zum crashen bringen können. Falls du noch nicht sichergestellt hast, dass alle Dienste nicht mehr Arbeitsspeicher wollen können als dir zur Verfügung steht, d.h. im Wesentlichen jeweils die maximale Anzahl an Prozessen beschränkt hast, solltest du das mal tun und dann den mysql server komplett neu aufsetzen.


    postfix läuft normal gar nicht chrooted. Zumindest steht in der chroot-Spalte in der master.cf überall ein "-" oder ein "n".


    Ich glaube nicht, dass dem Server irgendwie der Speicher ausgeht. Wenn ich morgens den abgeschmierten Server untersuche, sind so 120 von 200 MB belegt. Nachdem ich MySQL dann neu gestartet habe und smtpd dann alle Mails noch verteilt hat, sind es nur noch 80 MB.


    Wo bzw. wie soll denn nachts ohne Last dem Server der Speicher ausgehen? Tagsüber läuft er ja immer einwandfrei und auch performant. Es lief ja auch alles über Monate einwandfrei.


    Ich vermute immer noch, dass das etwas mit dem neuen Kernel oder meinem VM-Backup zu tun hat ...


    Wenn es morgen wieder auftritt, schmeisse ich MySQL mal komplett runter und installiere es neu.


    Gruß
    Konni

  • Hmm also ich hab das Problem nicht -.-*
    Server neu aufgesetzt mit syscp und etch alles schön brav geupdatet die packete aus deiner liste vorher natürlich was gefehlt hat nachinstalliert. aber bisher Ohne Probleme.


    Hab übrigens gleich mal die lods eingeschaltet das falls die Nacht was abschmiert da fehler gibt ;)
    Also heißts nun warten würd ich vermuten



    MfG
    Andre

  • ähmmm lol hab kleines Update für euch ;)


    Syscp mit Etch frisch installiert und 99_syscp_vhost.conf leer


    Ich würd mal glatt sagen das das nen Fehler im image direkt sein könnte.
    Sofern das mal jemand vom Support liest kann man da ja mal schauen ;) es lief noch kein cron garnix. Die Problematik hatten wa hier im Forum glaub ich schon öfter also denk ich mal das Netcup da am image was verändert hat und dasn Bug ist ^^


    Alle anderen Dienste laufen aber trotzdem einwandfrei ohne Fehler



    MfG
    Andre

  • Hi Andre,
    danke für deine Arbeit bisher ... warte mal die erste Nacht ab. =)


    BTW: Das mit den vhosts juckt mich nicht - ich setze ja eh einen selbst konfigurierten lighttpd ein - gänzlich ohne vhosts.


    Gruß
    Konni

  • ... und täglich grüßt das Murmeltief ... ;)


    Gibt es eine elegante Möglichkeit MySQL komplett zu sichern (inkl. der MySQL-User)? Oder sind die MySQL-Nutzer auch in der mysql-Tabelle enthalten und es reicht alle DBs zu sichern?


    Dann mache ich später im Laufe des Tages mal eine MySQL-Neuinstallation.


    Gruß
    Konni

  • http://www.mysql.de/products/backup/


    Sollte alles dort stehen denk ich. Da gibts verschiedene Varianten.



    Mein Testsystem läuft übrigens immernoch sauber ohne Probleme keine Fehler garnix. Das einzige is halt der Bug im image Debian Etch+SyCP


    Das was evtl. noch sein könnte is das irgendne Anwendung die aufn Web installiert ist Tabellen hat die die DB abschießen. indem Fall würde dir die neuinstallation denk ich auch nix bringen.


    Einfach ausprobieren würd ich sagen.


    MfG
    Andre

  • So, ich habe jetzt mal MySQL neu installiert ... leider muss ich bis nächste Nacht warten ... =)


    Ansonsten werde ich vielleicht einfach mal auf Lenny upgraden und hoffen, dass das durch neue Programmversionen glatt gebügelt wird.


    Gruß
    Konni

  • Ich hatte mich mittlerweile wegen des hier genannten Verhaltens bezüglich des Loopbacks an Netcup gewandt. Daraufhin hat man mir mitgeteilt, dass man das Verhalten heute durch einen Wechsel des Kernels von Version 2.6.29.5 auf die aktuellste Version 2.6.31.6 beheben wird. Der vorherige hatte wohl einen Fehler im Netzwerkstack. Mit dem neuen Kernel funktioniert das Loopback nun wie es sich gehört.

  • Wie kann ich denn den Kernel des Hostsystems herausfinden? Mit uname -a kriege ich ja nur den Kernel des Gastsystems, oder?


    Gruß
    Konni


    PS: Das Problem hat sich immer noch nicht erledigt ... ich werde heute Abend wohl mal das Upgrade auf Lenny fahren.

  • Zitat

    Wie kann ich denn den Kernel des Hostsystems herausfinden? Mit uname -a kriege ich ja nur den Kernel des Gastsystems, oder?


    Nein, dass ist der Kernel des Node, dein vServer hat keinen eigenen Kernel, du hast also keinen Einfluss auf den Kernel und dessen Version

  • Zitat von Konni;9695

    PS: Das Problem hat sich immer noch nicht erledigt ... ich werde heute Abend wohl mal das Upgrade auf Lenny fahren.


    Hi,


    dann berichte ob es Erfolg hat. Ich habe exact das gleiche nur die die Frequenz bei mir nicht so hoch. Bei mir hakts alle 15-20 Tage....