Im Artikel „MySQL Cluster oder Hot-Stand-By Lösung? Eine Frage der Hochverfügbarkeit“ haben wir die Vorüberlegung getroffen, wie wir unser System aufbauen möchten. Da wir einen Master-MySQL-Server und mehrere Slave-MySQL-Server haben und die Daten nicht jederzeit zu 100 Prozent synchron sein müssen, können wir die MySQL Replikation (Log-Shipping) nutzen. Ein weiterer Nachteil dieser Lösung ist, dass keine Daten auf dem Slave-Server verändert werden sollten/dürften, da sonst die Datenbestände auseinanderlaufen. Da in unserem Fall hauptsächlich Abfragen getätigt werden und SQL-Inserts nur zur Besucherstatistik dienen, kann das Zusammenführen dieser statistischen Daten über einen Cron-Job nachts erfolgen. Dieser sendet die Tagesdaten an den Master-Server, der diese Daten zentral aufbereitet. Die Replikation dieser Daten ist nicht gewünscht.
Weitere vorbereitende Überlegungen
Damit die MySQL-Replikation auch ordnungsgemäß funktioniert, sollten die MySQL-Versionen zwischen Master und Slave übereinstimmen. Kleine Versionsunterschiede können kein Problem sein, können aber auch zu zeitraubenden Fallen werden. In meinem Testsystem nutze ich unterschiedliche Versionen; es klappt einwandfrei. Allerdings muss dies nicht für alle Versionsdifferenzen gelten. Um die installierte MySQL-Version der einzelnen Server zu prüfen, können wir folgenden Befehl (Putty-Konsole) nutzen:
Prüfe die MySQL-Version
Putty: mysql -h localhost -V
Mit Netz und doppelten Boden
Wenn irgendwie möglich, sollte vor Start von jedem Member (Master und Slave) Images gemacht werden. Bei den folgenden Schritten kann die MySQL-Datenbank fehlerhaft werden, was bei softwaregestützten Webservern (Plesk, Confixx) zu einem Ausfall führen kann!
Einrichtung der MySQL-Replikation auf dem Master-Server
Als erstes müssen wir auf den MySQL-Master-Server einen Replikations-Benutzer anlegen. Weitere Informationen zu diesem Thema hält die MySQL-Seite vor. Wir öffnen eine Putty-Sitzung mit dem Master-Server und loggen uns in die MySQL-Konsole ein:
MASTER:
mysql -u root -p [RETURN]
MySQL-Replikations-Benutzer anlegen
Nehmen wir nun an, dass unsere Domäne mydomain.com heißt und wir ein Konto mit dem Benutzernamen „repl“ erstellen wollen. Dieses Konto nutzen die Slave-Server unter Angabe des Passworts „slavepass“ und stellen so die Verbindung Slave-Master her. Hier sehen wir also, dass der Zugriff (lesend) vom Slave oder den Slaves zum Master funktioniert.
Das Replikations-Konto erstellen wir mit folgender GRANT-Anweisung (Hinweis: Wir benötigen an dieser Stelle Root-Rechte):
mysql> GRANT REPLICATION SLAVE ON *.*
-> TO ‚repl’@’%.mydomain.com‘ IDENTIFIED BY ’slavepass‘;
My.conf auf dem Master anpassen
Nun öffnen wir mit einem Texteditor unserer Wahl die „etc/mysql/my.cnf“ und setzen die untenstehenden Werte (je nach Installation sind diese Werte vorhanden; wir entfernen lediglich die Auskommentierung „#“)
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
Was bewirkt diese Änderung: Wir teilen MySQL mit, dass dies der Server 1 ist. Alle an der Replikation beteiligen Server benötigen eine eigene (unterschiedliche ID). Per Eintrag „log_bin“ weisen wir MySQL an, dass alle Datenbankänderungen ab sofort geloggt werden sollen (an der Stelle: /var/log/mysql/mysql-bin.log)
Den MySQL-Server restarten
Damit die Änderungen aus der my.conf auch greifen, muss der MySQL-Dienst neu gestartet warden:
/etc/init.d/mysql restart
Nun müssen wir den aktuellen Stand der Datenbank sichern. Dieser Datenstand wird auf die Slaves verteilt. Alle folgenden Transaktionen auf den Slaves erfolgen dann über das Log-Shipping.
Vorbereitung für das Abbild der Master Datenbank erstellen
Über die MySQL-Konsole sperren wir alle Schreibzugriffe auf die Datenbank:
FLUSH TABLES WITH READ LOCK;
Position vom Master-Logfile notieren
Der folgende Schritt ist sehr wichtig. Wir notieren uns die aktuelle Position vom Master-Logfile. Diese Daten benötigen wir später beim Start der Slave-Synchronisation (Abschreiben oder Hardcopy)
SHOW MASTER STATUS;
Abbild vom aktuellen Stand der Master Datenbank erstellen
Wir öffnen via Putty eine weitere Sitzung. Die Putty-Sitzung mit dem „LOCK“ lassen wir bestehen und schließen sie nicht! Mit dem folgenden Code gehen wir in das MySQL-Verzeichnis und sichern die Datenbank:
cd /var/lib/mysql
tar -cvf /root/mysql-snapshot.tar
ACHTUNG: Zu beachten gilt hier, dass wir so ALLE Datenbanken des MySQL-Servers sichern (und später auch wiederherstellen). Je nach Server-Verwaltungssoftware (zum Beispiel Plesk) sind diese Daten auch in der MySQL-Datenbank gespeichert. Wenn wir diese Daten auf dem Slave-Server einspielen, überschreiben wir die MySQL-Plesk-Daten (oder andere MySQL-Einträge) auf dem Slave-Server. Ich gebe an dieser Stelle einmal zu, dass ich so schon einmal einen Plesk-Webserver „zerschossen“ habe).
Wollen wir also nur eine Datenbank replizieren („this_db“), nutzen wir folgenden Befehl:
shell> tar -cvf /root/mysql-snapshot.tar ./this_db
Die Datenbank auf dem Master wieder freigeben
Über unsere bestehende MySQL-Konsole setzen wir folgenden Befehl ab:
UNLOCK TABLES;
Nun haben wir also den Master-Server für die MySQL-Logfile-Replikation vorbereitet und ein Abbild der Master-Datenbank erstellt. Im Artikel „MySQL Replikation auf den Slave-Servern einrichten und starten“ beschäftigen wir uns mit den Slave-Servern.