hi.
der server search.nickles.de leidet unter einem sehr merkwuerdigen problem: auf der kiste laueft ein suse 7.2 (vorher ein 71., da gabs aber das gleiche problem). darunter laeuft ein aktuelles mysql und ein aktueller apache mit php und zend.
einmal am tag wird die nickles.de datenbank auf diesen rechner gesichert ( ca. 700 mb ), einfach per secure copy von einer anderen maschine.
das klappt auch alles ganz wunderbar - zumindest so 4-6 wochen lang. danach korrumpiert irgendwas das filesystem, sodas der rechner gebootet und fsck manuell aufgerufen werden muss... dann gehts wieder einige wochen gut - und dann passiert wieder das gleiche.
jedesmal ohne vorwarnung.
was ich braeuchte waere entweder eine loesung wie man das grundsaetzlich loswird, oder aber zumindest ein automatischer mechanismus der sich selbstständig um das booten und fsk aufrufen kuemmert...
WM_THX
thomas woelfer
Linux 15.036 Themen, 107.107 Beiträge
was für ein filesystem benutzt ihr denn?
ext2
Also:
1. Wenn ihr einen Kernel unter 2.4.10 benutzt und als Filesystem Reiserfs liegt es daran. Erst ab Kernel 2.4.10 ist der Patch implementiert.
Ansonsten würd ich vorschlagen via Crontab das Fielsystem alle 12 Stunden überprüfen lassen.
Oder ein Script schreiben das die Systemwarnung ausliest und bei einer bestimmten Meldung direkt die Platte fsckt.
Ansonsten musst du unter SuSE die maximale Anzahl der Mounts der Platten niedirger stellen ( Das kann man machen, hab leider vergessen wo).
Oder ihr ändert eurer Rechnerverhalten ebenfalls via Crontab und lasst das Ding alle 12 Stunden rebooten ( oder so ähnlich) was aber die bescheidenste Lösung wäre (c:
Hoffe geholfen zu haben,
Grüße
Kirin
Wer kann das Problem lösen?
Wie geht ihr da ran?
nur eine vermutung, aber könnte es sein, daß während der sicherung zufällig schreibzugriffe auf die datenbak erfolgen, die das filesystem beschädigen während der laufenden sicherung?
nope. auf die datenbank wird nur lesend zugegriffen. wuerde aber auch keine rolle spielen: die sicherheitskpie ist filebasiert und landet an einer ganze anderen stelle. erst wenn alles rueberkopiert wurde, werden die daten aus der kopie ins mysql geladen.
WM_THX
thomas woelfer
wie wäre es , wenn Ihr Reiserfs mit eingeschalteter Fscontrolle in den Kernel einbaut.
Ich kenne ähnliches, benutze ebenfalls SuSE 7.2 und fahre mit dieser Lösung plus softdog-kernelmodul ganz gut, allerdings muss die Reaktionszeit zum automatischen reboot angepasst werden an eure bedürfnisse
Reiser auf einem Server? Niemals! Ich habe hier auf meinem Desk Reiser und devfs und noch nie Probleme, aber auf meinem Server wuerde ich das nie draufmachen, dafuer ist es noch zu unsicher.
Klaus
Hast du denn irgendwelche Meldungen im Log stehen? Koennte es ein Hardware-Problem sein, eventuell RAM, CPU zu heiss?
Was passiert denn genau? Bleibt die Kiste einfach stehen? Kann man denn weiterhin darauf zugreifen?
Klaus
im log steht nix; abgesehen davon das er irgendwann anfaengt das filesystem zu bemaengeln. sobald das passiert laeuft der rechner zwar noch und man kann auch drauf zugreifen (ssh...) aber alles was irgendwie auf die platte zugreife will (lesend oder schreibend) geht praktisch nicht mehr. d.h. z.b. das da zwar noch ein apache laeuft, aber nicht mehr auf requests anwortet (will die per zend verpacken und per ...name gerade vergessen... komprimieren - und das gehthalt nicht. darum keine antwort....
m.a.w: einfach so durch anpingen merkt man nicht das irgendwas nicht stimmt - nur wenn man dann von aussen einen diesnst benutzen will (eben search.nickles.de) gehts nicht...
WM_THX
thomas woelfer
Also, von solch einem Problem habe ich noch nie gehoert. Ihr startet den Apache doch nicht durch die inetd.conf, oder? Aber dann wuerde etwas im Logfile stehen.
Hast du mal geprueft, ob noch genug Inodes verfuegbar sind, wenn das passiert (df -i)? Ein ext2 schrottet sich nicht einfach so.
Welchen Kernel habt Ihr? Ist das ein frueher 2.4.X, der den Swap vollmuellt? Ab 2.4.6 kann man erst mit dem neuen arbeiten.
Bye, Klaus
tja, hier schrottet es sich eben doch :( - egal ob mit neuem oder alten kernel, schon beides ausprobiert. nach 6 (?) wochen gibts einen crash und nix geht mehr...
Sorry, dann weiss ich auch nicht mehr weiter, ausser in der /etc/crontab eintragen:
* * 1 * * root /sbin/init 6
Um die Kiste an jedem 1. zu rebooten. Dann muesste die doch eigentlich wieder fuer 4 Wochen laufen.
Klaus
naja, booten reicht halt nicht, weil das fsck ja ausgefuehrt werden will... :)
WM_THX
thomas woelfer
Dann setze mit tune2fs entweder auf 1xbooten oder die Zeit auf 27 Tage, damit bei jedem booten fsck augerufen wird.
man tune2fs ;-).
Bye, Klaus
WM_THX
-t
Laut meinen bescheidenen Datenbankkenntnisssen, denke ich könnte es daran liegen das die Datenbank irgendwo anders noch Einträge macht oder exklusiv geöffnet ist. Dann wäre ein Filesystem-Check selbstverständlich. Versuche einfach einmal die Datenbank im runlevel S auf dem selben Computer zu sichern und prüfe dann ob du beim Starten auch wieder einen Filesystem-Check machen mußt.
Hier noch ein paar interessante Links:
--) Datebank Knowledgebase zum Durchsuchen
www.mimer.com/developer
--) Auftretende Probleme bei der Sicherung/Wiederherstellung von Datenbanken:
http://developer.mimer.se/documentation/Mimer_SQL_Technical_Description/Security4.html
Gruß rootthk
mailto:rootthk@napigator.com