Heute ist bei einer Konfiguration einer MySQL Master-Slave Replikation ein merkwürdiger Fehler aufgetreten, dessen Lösung ich erst nach langem Suchen im Internet gefunden habe. Damit es andere vielleicht schneller finden, möchte ich ihn hier beschreiben. Und weil es so schön dazu passt, noch ein kleines Mini-Tutorial, wie man eine einfache Master-Slave Replikation unter MySQL aufsetzt.

Sinn und Zweck ist, dass am Ende die Datenbank auf dem Slave eine identische Kopie der Master-Datenbank ist. Dies kann u.a. zu Sicherungszwecken nützlich sein.

Die Master-DB vorbereiten für die Replikation

In die Datei /etc/mysql/my.cnf (Sektion mysqld) wird ergänzt:

server_id = 1
log_bin = /var/log/mysql/mysql-bin.log
log_bin_index = /var/log/mysql/mysql-bin.log.index
relay_log = /var/log/mysql/mysql-relay-bin
relay_log_index = /var/log/mysql/mysql-relay-bin.index
expire_logs_days = 10
max_binlog_size = 100M
log_slave_updates = 1

Danach den Benutzer für die Replikation erstellen:

mysql> GRANT REPLICATION SLAVE ON *.* TO ‘replication’@'<slave-server-ip>’ IDENTIFIED BY ‘<super kennwort>’;
Query OK, 0 rows affected (0.02 sec)

Damit die neuen Werte übernommen werden, einmal MySQL neu starten.

Kopieren der Daten auf den Slave-Server

Damit nachher auf beiden Servern zum Start der Replikation identische Datenbanken vorliegen, müssen wir feststellen, an welcher Stelle wir aktuell schreiben. Dazu halten wir erst alle Datenbankvorgänge an.

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.04 sec)

Am Besten stoppt man auch kurz die Prozesse, die auf die Datenbank zugreifen möchten (vor allem Schreibende). Dann geht es an das Kopieren und merken des korrekten Replikationsstarts:

mysql> SHOW MASTER STATUS;
+——————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000001 | 8741 | |
|+——————+———-+————–+——————+
1 row in set (0.00 sec)

Achtung: Diese MySQL-Shell nicht zumachen, da sonst der Lock entfernt wird! Auf einer neuen Ebene die Daten exportieren:

#mysqldump -u root -p –all-databases > /tmp/database-backup.sql

Dann den Dump kopieren:

# scp /tmp/database-backup.sql <slave server>:~database-backup.sql
52% 3096MB 8.7MB/s 05:24 ETA

und einspielen:

root@<slave server>:~# mysql -u root -p < database-backup.sql

Bei Debian muß auch die /etc/mysql/debiError_code: 1045an.cnf angepasst werden, da wir die komplette mysql-user Tabelle auch kopieren. Danach MySQL neustarten oder flush privileges. Wir können nun die Datenbanken auf dem Master Server wieder frei geben:

mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)

Synchronisation einrichten

Es liegen beide Datenbanken identisch vor ab einem gesetzten Zeitpunkt. Um die Replikation zu starten, führen wir auf dem Slave aus:

mysql> CHANGE MASTER TO master_host=’<MASTER HOST>’, master_port=3306, master_user=’replication’,
master_password=’<KENNWORT VOM REPLICATION USER>’, master_log_file=’mysql-bin.000001′, master_log_pos=8741;
Query OK, 0 rows affected (0.07 sec)

Die entsprechenden Werte für die Position und dem Logfile entnehmen wir dem weiter oben auf dem Master ausgeführtem Kommando. Die eigentliche Replikation starten wir nun mit

mysql> START SLAVE;

Den Status kann man mit einem”Show Slave Status” einsehen. Ist alles gut gegangen, baut der Slave eine Verbindung zum Master auf und wartet auf Änderungen, die vom Master gesendet werden.

Der Fehler

Erst beim Status erhielt ich einen Fehler:

[ERROR] Slave I/O: error connecting to master [....] Error_code: 1045

Die Lösung:

Das Kennwort für MySQL unterliegt keiner Längenbeschränkung – das vom Replikation-User darf allerdings nur 32 Zeichen lang sein. Daher sieht das Kennwort korrekt aus, wenn man es über die Konsole verifiziert – nur eben die Replikation funktioniert nicht.

Viel Spaß beim Einrichten!

Weil es gerade so aktuell ist: mod_security2 in der neueren Version lässt sich nicht mehr über .htaccess abschalten. Um es dennoch per VHost kontrollieren zu können reicht ein Eintrag in der entsprechenden vhost.conf:

SecRuleEngine Off

Diese Anweisung kommt in die <VirtualHost…>…</Virtualhost> Umgebung, nicht in die <Direcorty>…</Directory>. Damit ist es auch unter Confixx über die httpd-specials möglich, mod_security per User auszuschalten.

Unsere neue Webseite unter www.net-publics.de steht kurz vor dem kompletten Relaunch. Aber das gewisse Etwas fehlte uns noch. Schnell war da die Idee geboren, eine Tag-Cloud über die am meisten besuchten Produktseiten zu erstellen. Ein Blick in das Extension Repository von Typo3 brachte da erstmal Ernüchterung: keine fertige Extension verfügbar. Also war selber machen angesagt.

Das Problem war leicht in zwei zu unterteilen: Einmal die Tag-Cloud an sich und dann die Seitenzugriffe ermitteln in Typo3. Daraus eine Kombination würde die “Top-Content Cloud” ergeben.

Für die Ermittlung der Seitenzugriffe in Typo3 habe ich mich der Extension Simple hit statistics (sys_stat) bedient. Diese zeichnet in einer externen Datenbank alle Anfragen ab, die an die Seite gestellt werden. Zugegeben, es wird noch mehr protokolliert als die Infos, die ich brauche, aber wer weiß, wozu das noch gut sein kann…

Folgendes SQL-Query übernimmt dann die Hauptarbeit:

select count(b.title) as weight,
a.page_id, a.IP,
b.title from sys_stat as a
left join pages as b on
a.page_id=b.uid
where unix_timestamp()-a.tstamp < 172800
and a.page_id IN ( $show_pages )
group by title;

Es werden hier also die Datenbanken des Statistiktools und die von typo3 verbunden. So werden nicht nur die Zugriffe, sondern auch die Seiten ID und deren Titel ausgelesen. $show_pages ist dabei eine einfache durch Komma separierte Liste der Seiten-IDs, die in der Cloud auftauchen sollen. Betrachtet werden nur die Daten der letzten 172800 Sekunden (2 Tage).
Das ganze Ergebnis lassen wir nun in einer Schleife in zwei Arrays schreiben, die es uns nachher einfacher machen, die Berechnungen der Größe durchzuführen:

while ($row = mysql_fetch_array($res)) {
$tags[ $row['title'] ] = $row['weight'];
$link[ $row['title'] ] = $row['page_id'];
}

Parallel dazu erstellen wir noch eine Übersicht über alle Seiten, die wir über das Plugin real-url ansprechen wollen, um schönere Links in unserer Cloud zu haben:

$page = mysql_query( “select page_id,spurl from tx_realurl_urldecodecache; “);
while ($row = mysql_fetch_array($page)) {
$realurl[ $row['page_id'] ] = $row['spurl'];
}

Wir haben nun drei Arrays: Die Tags mit zugehöriger Gewichtigkeit, die Seiten ID mit entsprechendem Link und zudem noch die Ergebnisse aus der real-URL Datenbank.

Jetzt kann es an die Cloud gehen:
Dazu erstmal ein paar Einstellungen, die ich jedes Mal von vorne berechnen lasse, da ich den Code in einer Funktion verwende, die nur die zu enthaltenen Seiten als Argument bekommt.

$max_weight = max(array_values($tags));
$min_weight = min(array_values($tags));

$max_font_size = 180;
$min_font_size = 80;

Hier werden die kleinsten und größten Werte aus dem Array heraus geholt und je Maximal- und Minimalwert für die Schriften gesetzt. Anschließend wird mit

$spread = $max_weight-$min_weight;
if (0 == $spread) { $spread = 1; }
$step = ($max_font_size – $min_font_size)/($spread);

die Abstufungen der Schriftgröße berechnet.
Jetzt können die einzelnen Tags der Reihe nach abgearbeitet werden:

foreach ($tags as $key => $value) {
$size = $min_font_size + (($value – $min_weight) * $step);
$size = ceil($size);
if ( $realurl[ $link[$key] ] != “” ) {
echo ‘<a href=”/’.$realurl[ $link[$key] ].’” style=”font-size: ‘.$size.’%”‘;
} else {
echo ‘<a href=”/index.php?id=’.$link[$key].’” style=”font-size: ‘.$size.’%”‘;
}
echo ‘ title=”‘.$key.’”‘;
echo ‘>’.$key.’</a> ‘;
echo “\n”;
}

Was passiert hier?
Zuerst berechnen wir die aktuelle Schriftgröße des Tags anhand der Wertigkeit (also der Anzahl der Seitenbesuche) und runden diesen Wert. Danach schauen wir, ob für diese Seite im Real-URL Cache ein Treffer vorliegt und geben diesen im Link aus. Ist kein Treffer vorhanden, verlinken wir auf die Seite anhand der Typo3-PageID. Zusätzlich wird in dem Link noch das title-tag auf den Seitentitel gesetzt.

Das fertige Ergebnis kann auf http://www.net-publics.de/ angeschaut werden.
Was noch ergänzt werden muß ist ein Schutz gegen das manipulieren der Tag Cloud. Das ist derzeit noch ganz rudimentär über mod_evasive geregelt, dazu in einem anderen Artikel später vielleicht mehr.