In den letzten Tagen konnte man häufiger beobachten, das der Webserver hinter babytux.de nicht erreichbar war. Trotz des netten Tipps von Sven B. brachte eine Änderung in der httpd.conf noch nicht gänzlich den erhofften Erfolg. Nun habe ich noch etwas an den Einstellungen für Timeout, den KeepAlive und MaxClients-Einstellungen herum geschraubt – in der Hoffnung, daß der Apache httpd nun nicht mehr so oft in die Knie geht.

Nebenbei hilft so ein Blick in die Log-Files um überhaupt mal festzustellen, wieviel Leute sich so an den hinterlegten Dateien auf meinem Server dank Direkt-Verlinkung bedienen. Anstand kennt man wohl auch nicht mehr – ich sag nur Trafficklau. Vielleicht hätte ich schon viel eher’ne .htaccess in einige Verzeichnisse legen sollen.

Image by Actu-Lan.com

Nun ja – da steh ich hier wieder und bin über aktuelle Probleme verwundert und lasse auch all die anderen Probleme der letzten gut zwei Jahre Revue passieren. Unzufrieden bin ich wahrlich nicht – dafür ist der Support bei vollmar.net zu gut. Aber richtig überzeugt bin ich spätestens seit den letzten Ausfällen auch nicht mehr. Rund ¤ 132,- pro Jahr sind in meinen Augen durchaus ein stolzer Preis, der es auch wert sein soll bezahlt zu werden. Zur Zeit bin ich jedenfalls nicht völlig überzeugt und habe mich spontan für ein – zumindest Übergangsweise – zweites Angebot entschieden:

Schon bei meiner damaligen Suche – beginnend vor über einem Jahr – trat irgendwann das Angebot von strato.de auf den Plan. Jedoch waren die Angebote – IIRC – damals noch recht jung im Programm. Entgegen meiner sonstigen Art bin ich dann mal spontan über meinen Schatten gesprungen worden und schaue mir in Zukunft den V-PowerServer A genauer an. Ich warte eigentlich nur auf meine Zugangsdaten.

Bei dem Köder-Lock-Schnäppchen-Angebot von drei Monaten zum kleinen Preis (bei 1-jähriger Bindung ) kann man sich mit Strato hinlänglich vertraut machen. Meine eng gesteckete Finanzplanung ist über das vierteljährliche Abrechnungs-Intervall jedoch nicht sonderlich begeistert.

So wird die ToDo-Liste für den anstehenden Urlaub immer länger und die Hoffnung, das ich zu irgendwas komme, was mit meinen Rechnern/Servern zu tun hat, gebe ich mittlerweile langsam auf. Kaum weiß jemand aus dem familiären Umfeld, das ich mal ‘ne Stunde morgens länger schlafen kann, werden wieder Spezial-Aufgaben mit Priorität “hoch” vergeben.

Ich versteh’s nicht wirklich.. schon wieder muckt mein vServer. Diesmal liegts anscheinend an meinem Apache-HTTP-Server. Dieses Phänomen, das der Apache geöffnete Verbindungen nicht richtig abbaut und dadurch entsprechend offen hält hatte ich vor einiger Zeit schon mal. Komischerweise trat das Problem kurzzeitig auf und war dann genauso schnell verschwunden, wie es kam. Nun schon wieder – wenn der Apache, eh begrenzt auf eine maximale Anzahl zeitgleich offener Verbindungen, dann irgendwann sperrt, verwundert es nicht, das man keine Antwort per HTTP bekommt.

Wer Ideen hat, woher sowas kommt, was es für Lösungsansätze gibt, ich bin für jeden Tipp offen.

Sowas ist einfach das i-Tüpfelchen, wenn man eh schon genug zu tun hat und den Kopf für sowas eigentlich gar nicht frei hat. An dieser Stelle noch kurz der Bahn gedankt, das ich überhaupt noch irgendwie, irgendwann zu Hause ankomme.

Wie der ein oder andere sicherlich feststellen konnte, war mein Blog in den letzten Stunden vermehrt nicht erreichbar. Ursache dafür waren wohl Hardware-Probleme meines Hosters.

Wollen wir hoffen, daß nun alles getauscht ist und die Probleme in Zukunft nicht mehr bestehen. Mittlerweile nimmt der von mir eigentlich ungeliebte Mailverkehr eine größere Rolle ein und da fällt es schon massiv auf, wenn der IMAP-Server auf einmal nicht mehr erreichbar ist.

Hin und wieder schaut man ja mal über seine Server und guckt nach, ob noch alles rechtens ist. Die überquillenden Apache-Log-Dateien ist man ja gewöhnt, das aber /var/log/mysql 1,9GB groß ist verwunderte mich dann doch. Drin befanden sich einige, rund 100MB große mysql-bin.*-Dateien.

Das Binärlog enthält alle Anweisungen, die Daten aktualisieren oder hätten aktualisieren können (beispielsweise eine DELETE-Anweisung ohne zutreffenden Datensatz). Die Anweisungen werden in Form von „Ereignissen“ gespeichert, die die Änderungen beschreiben. Ferner enthält das Binärlog auch Informationen dazu, wie lange die Ausführung datenverändernder Anweisungen jeweils gedauert hat.(..)
Der primäre Zweck des Binärlogs besteht darin, eine möglichst vollständige Aktualisierung von Datenbanken im Zuge eines Wiederherstellungsvorgangs zu ermöglichen, denn das Binärlog enthält alle Updates, die nach Erstellung einer Sicherung erfolgten. Außerdem wird das Binärlog auf Master-Replikationsservern zur Aufzeichnung von Anweisungen verwendet, die an Slave-Server gesendet werden.

Da der Plattenplatz auf meinem vServer nunmal begrenzt ist muß man eben an vielen Ecken sich auf das Nötigste beschränken. Also wurde einfach mal das Binär-Logging von mir deaktiviert. Einfach in der my.cnf irgendwo unter /etc – je nach Distribution – folgende zwei Zeilen auskommentieren:

log_bin = /var/log/mysql/mysql-bin.log
max_binlog_size = 100M

Die schon angelegten Dateien kann man im Zweifel auch entfernen. In Bezug auf Backups/Recovery hab ich für mich heute einfach ein neues Motto kreiert:

No risk – no fun! Redundanz ist was für Warmduscher

Bin mal gespannt, wann ich mir diese Weisheit selbst um die Ohren haue. Zur Zeit fehlt noch der Plattenplatz für eine schöne Backup-Sammlung. Ich hoffe bis spätestens Mitte nächsten Monat sieht das anders aus. Immerhin dusche ich auch gerne warm.