MySQL: Binärlog sicher automatisch löschen

von

Wenn ein MySQL-Datenbankserver per Replikation einige Tage in Betrieb ist, häufigen sich die Binär-Logs im MySQL-Verzeichnis. Zur Erinnerung: Ein Master-MySQL-Server speichert in seinem Binär-Log alle Transaktionen, die seine eigene Datenbank verändern. Der oder die Slave-Server greifen auf dieses Binär-Log zu und replizieren so anhand dieser Historie ihre eigene Datenbank. Ein Löschprozess findet per Standard nicht statt.

Auch wenn die Datenbank sehr klein ist, kann der Umfang der Binär-Logs einen stattlichen Umfang annehmen. Dies liegt weniger an der Größe der Datenbank – dies hat keinen primären Einfluss auf die Größe der Logfiles – sondern an der Anzahl der Insert und Updates, die eine Datenbank verändert haben. Jede einzelne Änderung findet sich im Binär-Log wieder. Wie wir in der Hardcopy hier sehen, schreibt der Beispiel-MySQL-Server seine Daten bereits in das 61. Logfile. Per Konsole erfahren wir, dass diese Logfiles bereits stolze 6,2 GB an Speicherplatz belegen, da in der mysql.cnf max_binlog_size  = 100M definiert ist; also jedes Logfile wird etwas größer als 100 MB.

Manuelle Löschung der MySQL-Binär-Logs
Prinzipiell ist das Löschen der Binär-Logs jedezeit möglich. Die Datenbank muss nicht angehalten werden und auch die Konsistenz des Master-Datenbankservers ist durch das Löschen in keinster Weise gefährdet. Warum auch? Der Master-Datenbankserver schreibt einfach fleißig sein Logfile. Er selbst stützt sich nicht auf die Logfiles. Wohl aber die Slave-Server. Wenn wir also Logfiles auf dem Master löschen, die ein Slave noch nicht verarbeitet hat, droht eine Inkonsistenz der Replikation. Also müssen wir jeden Slave fragen, mit welchem Logfile er gerade beschäftigt ist. Das älteste Logfile, das JEDER Slave bereits vollständig abgearbeitet hat, ist demnach das neueste Logfile, das gelöscht werden darf.

Ermittlung des aktiven Replikation-Logfiles
Wir loggen uns also auf jedem Slave-Server über die MySQL-Konsole ein und fragen nach dem aktiven Logfile:

# mysql –u root –p
mysql > SHOW SLAVE STATUS G

Über den Befehl SHOW SLAVE STATUS erfahren wir, welches das aktuelle Master-Logfile (Master_Log_File) und das Relay_Master_Log_File ist. Auf unserem Beispiel-Server würde im Statusbricht „mysql-bin.000061“ auftauchen. Wenn alle Slaves aktuell am 61. Logfile arbeiten, können die 60 Logfiles davor also gelöscht werden.

Entfernung der MySQL-Binär-Logfiles
Der folgende Befehl löscht die Binär-Files unwiderruflich. Ängstliche Administratoren können gerne Sicherheitskopien der zu löschenden Logfiles anfertigen. Sollte man sich einmal bei dem folgenden Befehl „verhauen“ und eine Inkonsistenz der Replikation erreichen, dann ist dies nicht der Untergang des Abendlandes. Man fertigt dann eine aktuelle Sicherung der Datenbank auf dem Master an, installiert diese auf dem Slave und startet dort die Replikation zu diesem Zeitpunkt neu.

Da wir keine Angst haben, löschen wir also die Logfiles. Zu beachten gilt: Die Angabe der Logfile-Nummer im folgenden Befehl ist exklusive; es werden also nur Logfiles BIS ZU DIESEM gelöscht. Wir können in unserem Fall alle 60 Logfiles löschen. Der Befehl dafür lautet also:

PURGE BINARY LOGS TO `mysql-bin.000061`

Automatisierte Löschung der Binär-Logs
Bei der routinemäßigen Überprüfung der Server kann der Administrator sicherlich die Binär-Files so löschen. Allerdings bietet MySQL auch die automatisierte Löschung an. Allerdings kann darüber nur ein Zeitraum in Tagen definiert werden. Ob der oder die Slave-Server auf dem aktuellen Stand sind, wird nicht überprüft. Aber auch hier gilt das gleiche wie bei der manuellen Löschung: Wenn einmal der Fall eintritt, dass die Inkonsistenz eintritt, muss die Datenbank auf dem Slave neu eingespielt werden. Ärgerlich, da mit Offline-Zeiten zu rechnen ist, aber kein Untergangs-Szenario.

In der MySQL-Konfigurationsdatei my.conf (/etc/mysql/my.cnf) finden wir den Eintrag “expire_logs_days=0“. Die „0“ setzt das Löschen außer Kraft. Wir setzten diesen Wert nun auf einen vernünftigen Wert. Ob

expire_logs_days=7

oder

expire_logs_days=30

die richtigen Werte sind, muss jeder MySQL-Datenbank-Administrator für sich selbst entscheiden. Da die Replikation der Slaves vom Administrator sowie ständig überwacht werden muss, dürfte ein so langes „Hinterherhinken“ eines Slaves sowieso nicht toleriert werden. In vielen Installationen sind heute bereits 10 Tage per default hiterlegt:

server-id        = 1
log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size         = 100M

Gimp: Bilder umwandeln von RGB nach CMYK

von

Die freie Grafikanwendung GIMP läuft sicher der professionellen Lösung Photoshop den Rang ab. Für semiprofessionelle Anwender ist GIMP sicherlich eine Alternative, denn die Grafikanwendung ist kostenfrei. In der Bedienung geben sich beide Anwendungen ebenfalls nichts: Ohne stundelanges Beschäftigen mit der Anwendung kommt man zu keinem Ergebnis. Erst wenn es um professionelle Lösungen für die Druckvorstufe geht, merkt man, dass GIMP langsam die Luft ausgeht. Es ist zu hoffen, dass die Entwickler hier noch nachbessern.

Wenn es um den CMYK-Farbraum geht, muss man Photoshop eindeutig den Vortritt lassen. Doch mit einigen „Tricks“ und Add-Ons kommt man auch mit GIMP weiter. So stellt einem beispielsweise das Umwandeln von Bildern von RGB nach CMYK erst einmal vor ein Problem, denn Gimp kann dies von Haus aus aktuell noch nicht. Für die Druckvorstufe werden jedoch Bilder benötigt, die bereits in die Druck-Farbanteile zerlegt sind. Um es gleich vorweg zu nehmen: Wenn man eine Druckerei hat, die RGB-Dateien entgegennimmt und diese Arbeit für einen geringen Aufpreis übernimmt, sollte man dies einen Spezialisten erledigen lassen. Denn am heimischen Monitor kann man nie sicher sein, dass eine Farbe später auch so gedruckt erscheint, wie gewünscht. Die Spezialisten in der Druckerei haben die Erfahrung und die technischen Möglichkeiten, dies schon im Vorfeld abzuschätzen und zu korrigieren.

Wer die Konvertierung von RGB nach CMYK mittels Gimp selbst vornehmen möchte (auch ich mache dies über diesen Weg – trotz der negativen Vorrede), muss zuerst sein Gimp erweitern. Die einzelnen Schritte zur Installation, Konfiguration und Farb-Konvertierung sind wie folgt durchzuführen:

  1. Neben der aktuellen Gimp-Version benötigen wir die aktuelle Version von „Separate+“. Zur Installation von Separate+ muss Gimp geschlossen sein.
  2. Entpacken Sie „Separate+“ in einem beliebigen Ordner (c:/tmp), denn wir benötigen nur einige Dateien aus dem Zip-Container.
  3. Die benötigten Dateien heißen „icc-colorspace.exe“, „seperate.exe“ und „seperate_import.exe“. Diese sind in der aktuellen Version im Verzeichnis „/separate+0.5.4/bin/win32_gimp2.4/“ zu finden.
  4. Kopieren Sie diese drei Dateien in das „plug-ins“-Verzeichnis von Gimp („C:\Programme\GIMP-2.0\lib\gimp\2.0\plug-ins“). Der entpackte Ordner von „Separate“ kann nun gelöscht werden.
  5. Ferner benötigen Sie Farbprofile, damit das Plug-In das Image korrekt aufarbeiten kann. Wir nutzen dazu die Adobe Farbprofile. Diese herunterladen und in einem Zielordner entpacken.
  6. Nun starten wir Gimp. Als erstes erstellen wir einen Verweis auf die Adobe Farbprofile. In Gimp wählen wir „Bearbeiten – Einstellungen“, dann in der linken Spalte „Farbverwaltung“. Im Bereich der „Farbverwaltung“ wählen wir nun im Drop-Down-Menü „CMYK-Profil“ „Farbprofil von Festplatte wählen“ aus.
  7. Im folgenden Fenster navigieren wir zum eben erstellten Ordner der „Adobe Farbprofile“ und wählen die Datei „CoatedFOGRA27.icc“ („Adobe ICC Profiles (end-user)“, „CMYK Profil“) aus. Nun steht das Profil auch unserem PlugIn „Separate+“ zur Verfügung.
  8. Öffnen Sie Ihr Bild. Achtung: Das Separate“-Plugin kann nur die gerade ausgewählte Ebene exportieren. Dies ist im Normalfall kein Problem, da die Farbseparation meist als letzter Schritt erfolgt. Vereinen Sie vorher alle Ebenen nach unten und wählen „Bild – Seperate – Seperate“. Im folgenden Fenster wählen Sie unter „Destination Color Space“ „Coated FOGRA27“ aus. Setzen Sie einen Haken bei „Make CMYK pseudo-composite“ und klicken Sie auf OK.
  9. In einem neuen GIMP-Fenster erscheint nun das von RGB nach CMYK umgewandelte Bild. Nicht erschrecken, das Bild wird sicherlich Ihnen rotstichig vorkommen. Dies ist kein Bug oder ein Fehler, sondern ein Problem der Darstellung, da das Bild nun in die vier Farbebenen (CMYK: Cyan, Magenta, Yellow und Key/Black) zerlegt wurde.
  10. Speichern Sie nun das Bild mittels „Bild – Seperate – Save“.

Nachtrag: Fehler: „Der Prozedureinsprungpunkt g_get_home_dir_utf8 wurde in der DLL libglib-2.0-0.dll nicht gefunden“

“Der Prozedureinsprungpunkt g_get_home_dir_utf8 wurde in der DLL libglib-2.0-0.dll nicht gefunden”. Wenn diese Fehlermeldung erscheint, müssen wir dem Plugin Seperate Plus eine eigene libglib-DLL hinzufügen.
“Der Prozedureinsprungpunkt g_get_home_dir_utf8 wurde in der DLL libglib-2.0-0.dll nicht gefunden”. Wenn diese Fehlermeldung erscheint, müssen wir dem Plugin Separate Plus eine eigene libglib-DLL hinzufügen.

Seit der Version 2.8.x funktioniert das Plugin nicht mehr reibungslos. Das Problem: Das Plugin benötigt eine veraltete „libglib-DLL“. Die Lösung: Wir stellen Gimp und somit dem Plugin diese DLL zur Verfügung. Die benötigten Dateien sowie das Vorgehen hat Simon Mueller in seinem Blog beschrieben.

Über 8 Millionen de-Domains

von

Anfang verpasst?

Es wird immer ein Glückspiel sein, ob ich eine wichtige Domain schnell erkenne, die gerade gelöscht ist. Im Netz sind einige der Ansicht, dass die wirklich wichtigen gelöschten DE-Domains binnen Minuten, wenn nicht gar Sekunden wieder neu registriert sind. Schneller als diese etablierten Spider werde ich wohl nicht sein. Hier ist Hoffnung fehl am Platz.
In einem Blog bin ich heute über die Meinung gestolpert, dass man gute gelöschte Domains nicht über eine DNS-Abfrage, sondern über eine Real-Whois-Abfrage findet. Der Autor ist der Meinung, dass alle Spider über die DNS-Abfrage gehen (was ich aktuell zumindest für meinen bestätigen kann) und man somit das Rennen verlieren wird (siehe auch der vorherige Absatz). Weiter ist er der Meinung, dass man auf Whois-Abfragen setzen sollte, da diese wohl fortlaufend aktualisiert werden, und nicht nur alle zwei Stunden. Ob dies stimmt, weiss ich nicht. Das interessante an der Sache ist jedoch, dass genau die Whois-Abfrage etwas ist, was ich schon vor Jahren für eine Handvoll Domains gemacht habe. Eben bis zu dem Tage, an dem die Denic eine Chapta-Prüfung eingebaut hat. Zudem sind nur ein paar Abfragen pro Tag und pro IP via Whois möglich. Vom Ansatz hat der Autor sicherlich recht. Denke, man könnte hier zweigleisig fahren: Die wichtigsten Domains per Whois, die weniger wichtigen Domains per Massen-DNS-Abfrage.
Ferner war der Autor die Meinung, dass man de/com/net/org-Domains vergessen kann. Zu groß sei die Konkurrenz, die ebenfalls nach diesen Domains auf der Suche ist. Er setze auf andere Top-Level-Domains. Sicherlich ist es da leichter, eine gute Domain zu erwischen. Ungeklärt ist meines Erachtens jedoch, die die Suchmaschinen-Tante reagiert, wenn man eine gute skandinavische Domain plötzlich mit deutschem Text bestückt und auch zu deutschen Domains linkt. Aktuell scheint dies noch kein Problem zu sein. Die „Tante“ scheint sich hier offenbar noch ein wenig „irreführen“ zu lassen. Es dürfte jedoch nur eine Frage der Zeit sein, wann hier Filter anschlagen.

Tag 14: Über 8 Millionen de-Domains
Nachdem seit über einem Tag keine neue Domain mehr in meinen Pool hinzugekommen ist, stand es fest: Mein Grabber muss einen Fehler haben. Nach langem Suchen fand ich den Übeltäter. Doppelte Verneinung und kein unscheinbarer Slash („/“) sorgten dafür, dass keine neue Domain mehr in die Datenbank hinzukam. Ich habe das Problem gefixt und über Nacht stieg die Anzahl der Domains von 76.000 auf über 200.000 an. Allerdings habe ich auch festgestellt, dass sich vermehrt doppelte Domains eingeschlichen haben. Dies kann eigentlich nicht sein, da jeder Insert per StoredProcedure auf das Vorhandensein der Domain zuerst geprüft wird. Es sieht so aus, dass die Datenbank mit den Anfragen nicht mehr hinterherkommt, denn die doppelten Einträge stammen aus der gleichen Sekunde. Daher habe ich im Grabber nun einen eigenen Cache eingebaut. Die letzten zehn Domains werden nun selbst in einer ArrayList gespeichert und zuerst darüber abgeglichen, bevor sie Richtung Datenbank geschickt werden. Der Performance des Grabber schadet dies nicht messbar, die Datenbank ist deutlich entlastet.
Beim googeln bin ich heute über einen alten Artikel aus dem Jahr 2004 gestolpert, in dem es heisst, dass die 8-Millionen-Marke bei de-Domains überschritten wurde.
Also habe ich noch einiges an Spiderarbeit vor mir …

Nachtrag: Der automatisierte Löschvorgang der doppelten Domains hat mal rund 60% der Datenbankeinträge wieder entfernt. Aktuell ist das Problem behoben, die Cache-Funktion entlastet den Datenbankserver enorm. Heute Nacht haben wir die 100.000-Domain-Marke nun wirklich ohne Dupletten überschritten.

Tag der wenigen Domains

von

Anfang verpasst?

Tag 13: Tag der wenigen Domains
Aktuell werden nur noch wenige Domains gefunden. Verwundert mich ein wenig. War schon auf der Suche nach einem Programmierfehler, den ich aber aktuell ausschließen kann. Denke es liegt daran, dass aktuell durch den Grabber hauptsächlich die verlinkten Domains aufgerufen werden, die nur Backlinks zu den Seiten haben, von denen der Grabber die Domain gefunden hat. Also der klassische 1:1-Link. Aber der Grabber wühlt sich weiter durch und ich habe noch Zeit. Denn die Datenbank mit weitern Domains zu füllen ist nicht das Problem. Momentan möchte ich eher schauen, wie sich die Datenbank selbst füllt. Immer im Hinterkopf: Der Grabber ist einmal von der Domain heise.de gestartet …
Vor einigen Tagen habe ich bereits geschrieben, wie ich zu einigen Domainlisten gekommen bin. Inzwischen hatte ich noch einige weitere Ideen, die ich irgendwann programmtechnisch umsetzen werde. Da sind neben dem Grabben von Webkatalogen / Linklisten natürlich die Keyword-Suche via Google. Die Domains der ersten 10 Google-Seiten sollten natürlich immer im Auge behalten werden. Wobei diese Domains ab einem bestimmten Füllungsgrad der Datenbank bereits in dieser enthalten sein sollte. Zum weiteren Füllen eignet sich auch die automatisierte Generierung der Domains. Es ist bekannt, dass alle dreistelligen DE-Domains bereits vergeben sind. Ich glaube, dass inzwischen auch alle vierstelligen Domains vergeben sind. Also bräuchte man nur einen kleinen Generator schreiben, der alle möglichen Zeichenkombinationen ermittelt. Aber auch hier habe ich Zeit, denn solche Domains sollten so schnell nicht gelöscht werden.
Aktuell mache ich mir noch weitere Gedanken zur Prüfung der Domainverfügbarkeit. Ich bin via Ping zur DNS-Abfrage gekommen. Diese klappt bereits soweit ganz gut. In der Regel werden die DNS-Server der großen Registrare alle zwei Stunden upgedatet. Es macht also Sinn, kurz nach einem Update alle bekannten Domains zu prüfen. Mit der nötigen Maschinenpower durchaus machbar. Vielleicht sollte man hier auch noch auf klassische Webserver setzen. Auch diese könnten die Abfrage durchführen. Bei allen bekannten Webhoster eine kleine Maschine mieten und ab geht die Post. Durch die geteilte Last und die Abfrage über verschiedene IP-Kreise kann so in kürzester Zeit die Domainliste abgefragt werden.
Allerdings stellt sich auch die Frage, ob dies überhaupt sein muss. Es gibt viele Domains, die mich von vorneherein nicht interessieren. Warum Maschinen- und Netzlast für diese Domains verschwenden? Aktuell führe ich eine Domainbewertung erst durch, wenn die Domain als gelöscht gekennzeichnet wurde. Es würde durchaus Sinn machen, die Bewertung durchzuführen, wenn die Domain neu gefunden wird. Gerade wenn nicht mehr tausende von neuen Domains pro Tag hinzukommen, macht dies Sinn. Für die Abfrage wiederum haben dann die Domains Priorität, die schon als wichtig bekannt sind.

Hier geht es weiter

Image Wechsel bei Mouseover mit CSS

von

Diesen Effekt sieht man im Internet häufig bei Menü- oder Navigationsleisten. Ein Image ändert sich – zum Beispiel die Schrift – wenn man mit der Maus darüber fährt. Der Effekt ist eigentlich einfach, denn anhand eines MouseOver-Ereignisses muss lediglich das Image ausgetauscht werden. Dies bedeutet, dass wir auf jeden Fall zwei Images benötigen.
Bisher hat man sich bei diesem Effekt meist auf JavaScript eingelassen. Der MouseOver-Effekt wurde per JavaScript abgefangen und das Image getauscht. Heute möchten wir den Effekt ausschließlich per CSS realisieren, denn der Effekt soll auch funktionieren, wenn Benutzer JavaScript deaktiviert haben. Ferner soll der Link, der hinter dem Image steckt, auch bei mobilen Browsern funktionieren, die kein CSS können. Aber gleich vorneweg: Der CSS-Effekt, den wir heute hier beschreiben, funktioniert bei allen aktuellen mobilen Geräten, mit denen ich ihn testen konnte.


LCD, LED oder Plasma-TV

Im vorliegenden Fall benötigen wir mehrere Images auf einer Seite, die zu speziellen Informationsseiten linken sollen. Diese Boxen sollen auffallen, aber eben nicht auffallen. Schwierig? Der Gedanke bei diesen Informationsboxen ist, dass sie ihrer Farbe beraubt werden und erst bei einem überfahren mit der Maus (MouseOver) ihre eigentliche Brillanz erhalten sollen. Dadurch, dass die Images „verwischt“ sind, fallen sie nicht sofort ins Auge und stören das eigentliche Layout nicht. Auf den zweiten Blick fallen jedoch die Images eben durch die zurückgenommene Brillanz auf und sollen neugierig machen.

Verblasstes Images mittels Gimp erstellen
Wir erstellen zuerst das fertige Image. In diesem Fall benötigen wir ein Image mit abgerundeten Kanten. Das fertige Image wird verblasst. Wie wir diesen Effekt am besten realisieren, ist im Artikel „Gimp: Bild verblassen lassen“ beschrieben. Wir benötigen also zum Schluss von jedem Image zwei Versionen. Das „strahlende“ und das „verblasste“ Image.

Image-Wechsel mit CSS umsetzen
Dem Image-Wechsel möchten wir mit CSS umsetzen. Hierzu fügen wir einen Link sowie einen Span-Container im Body an der gewünschten Stelle ein. Sollte CSS nicht funktionieren, wird der Text innerhalb der Span-Tags angezeigt. Der Link als solches wird immer funktionieren.
<a href=“http://www.mein-ziel.de“><span>Linktext</span></a>

Als nächstes benötigen wir einen CSS-Bereich. Für jedes Image benötigen wir eine eigene Klasse (was der einzige Nachteil dieser Variante ist). Wir blenden als erstes den Span-Tag aus und weisen dem dazugehörigen Link das Image als Background-Image zu.
Im Mouse-Over-Fall  („hover“: wir fangen auch „Active“ und „Focus“ ab) wechseln wir das Image aus.
Wir weisen also dem Link im „Normalfall“ das helle, im Hover- bzw. MouseOver-Fall das farbintensive Bild zu:

<html>
<head>
<TITLE>Image Wechsel bei Mouseover</TITLE>

<style type="text/css">

/* WechselImage 1 */
.wechselimg1 span {
    display: none;
}
.wechselimg1:link, .wechselimg1:visited {
    display: block;
	width: 239px;
	height: 58px;
    background:         url(kaffeetraeume_hell.png);
}
.wechselimg1:hover, .wechselimg1:active, .wechselimg1:focus {
    background-image:       url(kaffeetraeume.png);
}

/* WechselImage 2 */
.wechselimg2 span {
    display: none;
}
.wechselimg2:link, .wechselimg2:visited {
    display: block;
	width: 239px;
	height: 58px;
    background:         url(fernseher_hell.png);
}
.wechselimg2:hover, .wechselimg2:active, .wechselimg2:focus {
    background-image:       url(fernseher.png);
}

/* WechselImage 3 */
.wechselimg3 span {
    display: none;
}
.wechselimg3:link, .wechselimg3:visited {
    display: block;
	width: 239px;
	height: 58px;
    background:         url(rasur_hell.png);
}
.wechselimg3:hover, .wechselimg3:active, .wechselimg3:focus {
    background-image:       url(rasur.png);
}

</style>

</head>

<body>
<H1>Image Wechsel bei Mouseover</H1>

<a href="http://www.zieldomain.de" class="wechselimg1"><span>Kaffee</span></a>
<a href="http://www.zieldomain.de" class="wechselimg2"><span>TV</span></a>
<a href="http://www.zieldomain.de" class="wechselimg3"><span>Rasur</span></a>

</body>
</html>

Gimp: Bild verblassen lassen

von

Um ein Bild verblassen zu lassen, gibt es mehrere Möglichkeiten, dies in Gimp zu realisieren. Der Punkt „Verblassen“ in Gimp liegt nahe, ist jedoch nur in wenigen Fällen aktiv.

Abwedeln / Nachbelichten
Eine Möglichkeit, eine Grafik verblassen zu lassen, ist der Punkt „Abwedeln/Nachbelichten“ unter „Werkzeug/Malerwerkzeug“. Nach der Auswahl einen möglichst großen Pinsel wählen, dann mit dem Werkzeug über das Image fahren. Die Belichtung kann und muss vielleicht verändert werden. Wichtig ist bei diesem Verfahren, dass jede Stelle des Images mit dem Werkzeug überfahren wurde.

Deckkraft reduzieren
Die vielleicht bessere Möglichkeit ist, die Deckkraft der Ebene zu reduzieren. Hierzu muss das Image einer Ebene zugewiesen sein. Dann kann im Fenster „Ebenen“ die Ebene ausgewählt und mittels des Schiebereglers „Deckkraft“ die Deckkraft reduziert werden. Wenn der Hintergrund durchscheint, ist das Werk vollbracht. Eventuell ist es sinnvoll, noch eine transparente Ebene in den Hintergrund zu schieben.

Bereiche/Ränder verblassen lassen
Wie man Ränder eines Bildes verblassen lassen kann, habe ich bereits im Artikel „Gimp: Bild Rand ausblenden“ beschrieben. Dort geht es um die automatisierte Ausblendung aller vier Ränder. Je nach Einstellung kann dies auch auf weniger Ränder reduziert werden.
Oft steht man jedoch vor der Aufgabe, ein Bild zu einer oder mehreren Seiten auslaufen oder verwischen lassen, damit der Rand des Bildes nicht zu hart zum Hintergrund erscheint.
Für diese Aufgabe eignet sich der Gimp-Verlaufstyp „VG nach Transparent“ hervorragend. Wenn man beispielsweise ein Bild zum Rand hin verblassen lassen möchte, nutzt man als Verlaufsfarbe Weiß. Wir legen also im Fenster „Ebenen“ eine neue transparente Ebene an, die über dem Image liegt. Dann wählen wir im Werkzeugkasten „Farbverlauf“ „VG mach Transparent“ und stellen als Farbe die Hintergrundfarbe (Weiß) ein. Nun ziehen wir das Werkzeug vom Bereich, der die Hintergrundfarbe bekommen soll, zum Bereich, an dem der Farbverlauf enden soll. Hier muss man ein wenig experimentieren, bekommt aber sehr schnell brauchbare Ergebnisse.

Verlauf mit Radierer erstellen
Manchmal möchte man nur Teile oder einzelne Bereiche verwischen, verblassen oder auslaufen lassen. Für diese Aufgabe eignet sich der Radierer gut. Man wählt dazu eine passende Größe des Radierers aus und experimentiert mit der Deckkraft. Ich fange meist mit einer mittleren Einstellung an. Ich schiebe also den Schieberegler irgendwo zwischen 40 und 60 Prozent. Nun werden einfach die Bereiche oder Kanten des Bildes „wegradiert“, was in diesem Fall ein verwischen bedeutet.

Bereiche Transparent machen
Dieses Problem stellt sich immer wieder, ist aber sehr einfach zu lösen. Unter die Bildebene eine neue, transparente Ebene, einfügen (Ebene/Neue Ebene/Einfügen – Transparent). Dann auf der Ebene mit dem Image die Bereiche auswählen, die man transparent haben möchte. Nun wählt man Löschen oder drückt STRG+X. Die Auswahl wird transparent.

Runde Ecken
Wir möchten nun nicht darüber diskutieren, ob eine Ecke rund sein kann …. Abrundungen sind in Gimp sehr schnell und leicht zu erstellen. Wir nehmen eine Grafik auf einer Ebene und wählen „Auswahl/Abgerundetes Rechteck“. Dann stellen wir den Radius der Ecken ein. Angewendet wird uns eine Maske erzeugt. Diese muss nun invertiert werden. Dann können mittels Löschen die Bereiche entfernt werden. Wenn ein transparenter Layer unter unserem Image liegt, erscheint das Image als abgerundetes Image.

Sorgenkind WordPress: Performance verbessern mit einfachen Tipps

von

WordPress ist und bleibt das Content-Management-System der ersten Wahl. Es ist umsonst, sehr gut entwickelt und wird ständig weiter gepflegt. Die Installation ist einfach, geht schnell und man kann relativ schnell loslegen.

Jedoch wer seinen Webserver immer im Auge hat wird feststellen, dass WordPress mit der Zeit immer langsamer wird. Es wird speicherhungrig und die Performance sinkt. Hier ist nicht unbedingt die Schuld bei den Entwicklern zu suchen. Es ist vielmehr wie bei einem Auto. Nur fahren und ab und zu tanken langt nicht. Mit den Jahren muss man auch mal eine Inspektion machen und vielleicht auch überlegen, ob man den Dachgepäckträger wirklich braucht (und auch mal den Kofferraum ausmisten). So ist es auch mit WordPress. Man neigt gerade am Anfang dazu, dem System jedes Plugin zu spendieren (ob sinnvoll oder nicht) und man macht sich auch um die Datenbank keine großen Gedanken. Und dies rächt sich, irgendwann.

Hier meine Tipps für eine Performance-Verbesserung eines WordPress Blogs

  1. WordPress und seine Plugins stets aktuell halten. Man muss nicht gleich am Erscheinungstag ein Update machen, doch wenn ein Update vorhanden ist und man Zeit hat: installieren.
  2. Unnötige Plugins entfernen. Jedes Plugin benötigt für seine Arbeit CPU und Speicher. Teilweise führen die Plugins mehr oder weniger aufwändige Datenbankabfragen durch, die die Performance deutlich nach unten ziehen. Daher alle Plugins entfernen, die nicht wirklich benötigt werden.
  3. Die Datenbank im Auge behalten. Eventuell von Hand ab und an die Datenbank auf Inkonsistenzen prüfen und die Tabellen optimieren. Als Tipp kann hier das Plugin “WP-Optimize“ eingesetzt werden.
  4. Die Bilder ebenfalls prüfen. Ist die Auflösung optimal, können die Bilder verkleinert werden? Zu empfehlen sind hier auch Online-Dienste wie smushit.com oder andere.
  5. Wer wirklich hohe Zugriffe aus seinem Server hat, sollte sich Gedanken über einen Cache und eine Komprimierung machen. Ein Howto zu diesen Themen habe ich im Artikel „WordPress mit Cache beschleunigen: Plugin Quick Cache“ und „GZip: Webseite beschleunigen (Page Speed) durch Kompression“ veröffentlicht.
  6. Unnötige Artikel löschen. Hier sind die Revisionen gemeint, die WordPress automatisch anlegt. Dieses Thema habe ich im Artikel „WordPress beschleunigen – Revisionen einschränken“ und „WordPress Artikel mittels Plugin “Delete Revision“ löschen bereits ausführlich behandelt.
  7. Java-Script oder JQuery-Bibliotheken nicht vom eigenen Server nachladen, sondern von externen Quellen. Der Grund liegt einerseits an der meist besseren Serveranbindung von Google- oder Amazon-Servern an das Internet, als das dies der eigene Serverhoster bereitstellen kann, andererseits werden diese Standard-Bibliotheken dann auch gerne gecached, was ebenfalls zu einem nicht zu verachtenden Performance-Gewinn führen kann. Und letztlich spart man auch noch eine Menge Traffic. Wer sich mit dem Thema weiter beschäftigen möchte, findet im Artikel „Drei Gründe, warum wir Google JQuery für uns hosten lassen sollen“  (Englisch) weitere Informationen.

 

Wie man eine MySQL Replikation überwacht und repariert

von

Wer eine MySQL-Datenbank spiegelt (Master/Slave), muss die Replikation öfters kontrollieren, denn im laufenden Betrieb können sich Fehler einschleichen und die Replikation wird gestoppt. Wer denn beispielsweise eine Webseite per Load Balancer gespiegelt hat, wird seinen Kunden nicht auf jedem Frontend-Server die gleichen Daten präsentieren. Aus diesem Grund muss die Replikation überwacht werden. Heute möchten wir uns mit der prinzipiellen Überwachung auseinandersetzen. Denn nur wer weiß, was MySQL für Fehler erzeugen kann und wie man diese per Hand bereinigt, kann sich dann Gedanken um eine Automation oder Überwachung machen.
Dass ein Fehler bei der MySQL-Replikation vorliegt, kann beispielsweise über das Syslog („/var/lib/mysql/mysqld.log“) darauf stoßen. Oder die MySQL-Konsole meldet via SLAVE STATUS einen Fehler.

So ist prinzipiell bei einem MySQL-Replikations-Fehler vorzugehen:

  1. Anmelden an der MySQL-Konsole mittels „mysql -u root –p“ [RETURN], Eingabe des Passwortes.
  2. Abfrage des Replikation-Status mit „SHOW SLAVE STATUS G”. Das “G” steht für die formatierte Ausgabe.

Wenn der Slave einen Fehler meldet, ist dieser sowie das SQL-Statement, welches den Fehler verursacht hat, in der Statusmeldung ersichtlich. Nun ist zu prüfen, wie verfahren werden soll. Eventuell soll nur der fehlerverursachende Befehl übersprungen werden. Dann ist wie folgt zu verfahren:

  1. Den Slave stoppen mit: STOP SLAVE;
  2. Den Befehl überspringen mit SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
  3. Den Slave wieder zur Replikation anfahren mit : START SLAVE;
  4. Den Replikationsprozess überwachen mit SHOW SLAVE STATUS G
  5. Die MySQL-Konsole beenden mit: quit;

Erkennen, dass die MySQL-Replikation fehlerhaft ist
Über die MySQL-Konsolen-Befehl „SHOW SLAVE STATUS G“ erfährt man alles wissenswerte über den Prozess. Neben den Parameter „Last_Error“ und „Last_Errno“ sollte auf die Parameter „Slave_IO_Running“ und „Slave_SQL_Running“ geachtet werden.. Die Parameter „Last_error“ enthalten eine Fehlernummer und gegebenenfalls ein SQL-Kommando, das einen Fehler verursacht. Aus den Parametern „Slave […] Running“ erfährt man, ob die Replikation noch läuft. Wenn einer der beiden Parameter auf „NO“ steht (oft nur Slave_SQL_Running), dann muss man sich um die Fehlerbehebung kümmern.

Gerne gesehene Fehler einer MySQL-Replikation
Wer eine Datenbank repliziert und nicht nur auf dem Master, sondern auch auf dem Slave mit den Tabellen arbeitet, kann sehr schnell zu folgendem INSERT-Problem kommen. Dann nämlich, wenn der Master Datensätze in eine Tabelle einfügt und ein oder die Slaves in diese (replizierte) Tabelle ebenfalls Datensätze hinzufügen. Selbst wenn die laufende IDs über die Tabelle per „AUTO_INCREMENT“ hinzufügt, tappt man sehr schnell in die Falle und erzeugt einen doppelten Schlüssel (Duplicated Key). Denn die INSERT-Befehl auf dem Master, der vielleicht ohne explizite Angabe einer Datensatz-ID ausgeführt wurde („AUTO_INCREMENT“), wird über das Binär-Log auf dem Slave explizit, also genau mit der ID ausgeführt, die auch auf dem Master eingefügt wurde. Fügt jetzt auch noch der Slave in diese Tabelle auf dem Slave Datensätze hinzu, kann die ID bereits vergeben sein und die MySQL-Replikation schlägt fehl. Das Verhalten ist klar, denn wenn die Replikation die Vergabe der ID dem Slave überlassen würde, könnte so der Spiegel auseinanderlaufen.

Konfiguration eines Apache Load Balancer

von

Nun ist es endlich soweit, wir wollen einen Apache Load Balancer konfigurieren. Die Planungen für unser Web sind abgeschlossen (Planungen zum Aufbau für einen Apache Load Balancer). Ohne hier noch einmal auf die MySQL Replikation eingehen zu wollen, stellt sich die Systemkonfiguration wie folgt da:

Server 1: DNS, NS, Load-Balancer
Server 2: cl1.domain.de
Server 3: cl2.domain.de

Wir erreichen also über domain.de Server 1 und wollen die Anfrage per Load Balancer auf einen der beiden Web-Frontend-Server (cl1 und cl2) routen.

Apache-Module aktivieren
Wir benötigen auf unseren Frontend-Server nur das Modul „mod_rewrite“. Per Putty verbinden wir uns als Root auf die Server und aktivieren das Modul:

a2enmod rewrite

Danach starten wir den Apachen neu:
/etc/init.d/apache2 force-reload

Aktuell benötigen wir keine Session serverübergreifend, da wir programmseitig sichergestellt haben, dass ein User auf einem zugeteilten Server verbleibt (und die Zugriffe nicht über einen längeren erfolgt). Ansonsten sollten wir noch folgende Rewrite-Rule auf jedem Client (mit der richtigen cl-Adresse) hinzufügen:

[…]
RewriteEngine On
RewriteRule .* – [CO=BALANCEID:balancer.cl1:.domain.de]
[…]

Konfiguration des Load-Balancer
Unser Server mit dem Load-Balancer soll unter www.domain.de erreichbar sein. Dies müssen wir per DNS sicherstellen. Ferner benötigen wir die untenstehenden Apache-Module, die wir mit dem Befehl „a2enmod“ aktivieren können.

a2enmod proxy
a2enmod proxy_balancer
a2enmod proxy_http
a2enmod status

Den Apache neu starten
Wie nach jeder Konfiguration müssen wir den Apache-Dienst neu starten:
/etc/init.d/apache2 force-reload

Der Balance-Manager
Eine schöne Geschichte ist der Balance-Manager, den der Apache mitbringt. Dieser ist via http erreichbar. Über ihn können einige Informationen zur Laufzeit abgerufen und eingestellt werden.
Der Balance-Manager benötigt ein nach Möglichkeit passwortgeschütztes Verzeichnis. Per Plesk legt man dieses über die Oberfläche an. Per Konsole gilt der untenstehende Weg:

Anlegen des Verzeichnisses „balance-manager“
mkdir /var/www/balancer-manager

User/Passwort anlagen [USER]= „admin“ oder ähnliches
htpasswd -c /var/.htpasswd [USER]

Nun öffnen wir einen Texteditor
vi /var/www/balancer-manager/.htaccess

Eingabe im Editor
AuthType Basic
AuthName „Members Only“
AuthUserFile /var/.htpasswd
<limit GET PUT POST>
require valid-user
</limit>

So, nachdem nun die Vorbereitungen für den Balance-Manager abgeschlossen wurden, kommen wir zur eigentlichen Konfiguration. Diese findet in der Datei „vhost.conf“ (unter Plesk in „/var/www/vhost/domain.de/conf/“) statt.

Debian-Installationen gehen so vor:

cp /etc/apache2/sites-available/default /etc/apache2/sites-available/default_orig
cat /dev/null > /etc/apache2/sites-available/default
vi /etc/apache2/sites-available/default

Hinzufügen in der Config-Datei
Achtung, beachten Sie die „/“! Dies ist meist eine Fehlerquelle.
Hinweis für Plesk-Nutzer: In die vhost.conf gehört nur der Teil ab (inklusive) „ProxyRequests Off“ bis „</Location>“ (inklusive).

NameVirtualHost *
<VirtualHost *>
        ServerName www.domain.de
        ServerAlias domain.de
        DocumentRoot /var/www/
        ProxyRequests Off

        <Proxy *>
          Order deny,allow
          Allow from all
        </Proxy>

        ProxyPass /balancer-manager !
        ProxyPass / balancer://mycluster/ stickysession=BALANCEID nofailover=On
        ProxyPassReverse / http://cl1.domain.de/
        ProxyPassReverse / http://cl2.domain.de/
        <Proxy balancer://mycluster>
          BalancerMember http://cl1.domain.de  route=cl1
          BalancerMember http://cl2.domain.de  route=cl2
          ProxySet lbmethod=byrequests
        </Proxy>

        <Location /balancer-manager>
          SetHandler balancer-manager

          Order deny,allow
          Allow from all
        </Location>
</VirtualHost>

Zur Erklärung:

ProxyPass /balancer-manager !
Verzeichnisse, die hier mit „ProxyPass“ und „!“ angegeben sind, werden vom Load-Balancer ausgenommen; sie werden also lokal aufgerufen. Wenn Web-Statistiken wie Webalizer oder AWStats aktiviert sind, sollte dieses Verzeichnis ebenfalls hier aufgeführt werden.

ProxyPass / balancer://mycluster/ stickysession=BALANCEID
Wenn Cookies/Sessions serverübergreifend gelten sollen, muss hier die BALANCEID mit der Rewrite-Rule auf den einzelnen Frontend-Servern übereinstimmen.

ProxyPassReverse / http://cl2.domain.de/
Hier werden die einzelnen Frontend-Server aufgeführt. Auch wenn das System produktiv ist, kann hier jederzeit ein Server hinzu- oder weggenommen werden.

Apache-Dienst neu starten
/etc/init.d/apache2 force-reload

Hinweis für Plesk-Nutzer
Die Datei vhost.conf ist eventuell nicht vorhanden. Diese kann per Texteditor angelegt werden. Jedoch muss explizit nach jeder Änderung an der Datei der untenstehende Befehl ausgeführt werden, damit die Änderungen in der vhost.conf auch in die globale Apache-Conf übernommen wird.
/usr/local/psa/admin/sbin/websrvmng –reconfigure-vhost –vhost-name=[VHOST-NAME]

Weitere Konfigurationsmöglichkeiten
Dem BalanceMember können noch weitere Werte wie beispielsweise
BalancerMember http://:8080 min=10 max=50 loadfactor=2
BalancerMember http://:8080 min=5 max=25 loadfactor=1
mitgegeben werden.

Loadfactor: Dieser bestimmt die Gewichtung eines Balancer-Mitglieds. Wenn dieser nicht angegeben wird oder für alle Member gleich ist (zum Beispiel je 50), dann bedeutet dies, dass der Balancer jedem Frontend gleich viele User zuteilt. Wenn ich einem Mitglied eine geringere Zahl als einem anderen Frontend zuteile, wird dieser Server mit weniger User belastet.

Status: Status eines Balancer-Mitglieds
Cluster-Set lbmethod: Vom Balancer zur Anfragen-Verteilung verwendete Methode, entweder anhand der Anzahl (»byrequests« ) oder anhand des Datenaufkommens (»bytraffic« ) der Anfragen
Min: Minimale Anzahl ständig offener Backend-Verbindungen
Max: Maximale Anzahl ständig offener Backend-Verbindungen
Maxattempts: Maximale Anzahl zu tätigender Versuche bevor die Anfrage abgewiesen wird stickysession Name eines von den Backend-Server verwendeten, persistenten Cookies

Planungen zum Aufbau für einen Apache Load Balancer

von

In den Artikeln „MySQL Cluster oder Hot-Stand-By Lösung? Eine Frage der Hochverfügbarkeit“ und „MySQL Replikation (Master/Slave) einrichten„haben wir uns mit der Master/Slave-Funktionalität zur Replikation von MySQL beschäftigt. Der Grund für diese Tätigkeit war die Planung eines Web-Clusters, welches wir mit einfachen Mitteln erreichen wollen. Im heutigen Teil möchten wir uns mit dem Load-Balancer beschäftigen.

Anfänglich sind wir davon ausgegangen, dass wir einen MySQL-Master Server haben. Alle Clients bzw. alle Frontend-Server sollten via Webservice ihre Datenbankergebnisse abholen. Diese Architektur hätte zur Folge gehabt, dass der Datenbankserver geclustert werden muss. Planungen zur Folge gab es die Annahme, dass ein Frontend-Server genügen würde.
Schnell hat sich als eigentliche Schwachstelle der MySQL-Master-Server erwiesen, über den alle MySQL-Anfragen liefen. Da dieser Server auch regen Kontakt zum eigentlichen Datenbank-Master-PC in einem lokalen Netzwerk hält und auch noch als Fileserver „missbraucht“ wird, musste die Planung geändert werden. In der aktuellen Planung soll der Datenbank-Master PC nur noch die Datenbank für die Replikation bereitstellen. Alle Web-Frontend-Server haben eine eigene lokale MySQL-Datenbank, die als Slave für die Replikation dient. Jeder Web-Frontend-Server hat somit eine eigene Datenbank-Instanz, kann lokal die Anfragen behandeln und fällt im Fehlerfall als eine Komponente aus.

Folgende Gedanken liegen der aktuellen Planung zu Grunde

  • Web-Frontends zu clustern und auch noch einen geclusterten Datenbank-Server zu betreiben, bedeutet größere Wartung
  • Lokale MySQL-Instanzen bedeuten geringere Netzlast bei einer Anfrage bei keinen Mehrkosten, da MySQL lizenzfrei ist.
  • Die MySQL-Datenbank-Ausfallsicherheit ist noch größer, da mit jedem weiteren Web-Frontend die Anzahl der Spiegelung steigt.
  • Der MySQL-Master Server kann zu Wartungszwecken jederzeit abgeschaltet werden.

Ein Vorteil dieser Planung ist, dass jederzeit bei steigender Last der Webseite ein neuer Server in die „Farm“ hinzugefügt werden kann. Die Installation und Konfiguration des neuen „Farm-Mitglieds“ ist binnen weniger Stunden erledigt. Die Integration über den Apache Load Balancer bedeutet keinen nennenswerten Ausfall des Systems (apache restart notwendig).

Hot-Stand-By-Server als letzte Rettung
Auch der MySQL-Master Server könnte über die Konfiguration des Apache Load-Balancer als limitiertes Farmmitglied dienen. Er würde so, seiner eigenen Auslastung entsprechend, weniger Besucher als die vollwertigen Frontend-Server zugeteilt bekommen. Dieser Server kann jedoch auch als Hot-Standby-Server dienen. Wenn alle Frontend-Server ausfallen würden, könnte dieser als verbleibender Server die Anfragen beantworten. Dieser Fall sollte jedoch nie eintreten, da der Server mit der auf ihn zukommenden Last relativ schnell an seine Grenzen stoßen würde.

Zu bewerten ist noch, auf welchem Server der Load-Balancer installiert wird und ob mit einem Load-Balancer auszukommen ist. Aktuell ist der Load-Balancer auf einer separaten Maschine, die auch als Nameserver fungiert, installiert. Bei Ausfall dieser Maschine ist das Web nicht mehr erreichbar.

Die Konfiguration des Load-Balancers werden wir im nächsten Schritt behandeln.