MySQL Datenbank Replikation

Nur mit dem aktivierten Binary-Log ist das Setup des Master-Slave-Systems noch nicht vollständig. Es beginnt schon früher. Zunächst müssen die beiden MySQL-Installationen kompatibel zueinander sein. Das ist nicht bei allen MySQL-Versionen der Fall und die Replikationen liefern bei inkompatiblen Versionen bisweilen überraschende Resultate. Ob unterschiedliche Versionen zusammenarbeiten, zeigt die Kompatibilitätstabelle auf[2].

Auf dem Master ist ein Replikations-Account anzulegen, der das Privileg »Replication Slave« bekommt. Bei MySQL-Versionen unter 4.0.2 gibt es dieses Privileg nicht. Stattdessen funktioniert dann das »File«-Privileg.

Der Account lässt sich mit »grant« folgendermaßen anlegen:

grant replication slave on *.* to Slave@Host.domain.de identified by 'Passwort';

Der Platzhalter »Slave« entspricht dem Namen des Accounts. »Host.domain.de« wird durch den FQDN (Fully Qualified Domain Name) ersetzt. ´

Binary-Log aktivieren

Da ein MySQL-Server standardmäßig weder Master ist noch das Binary-Log verwendet, muss man nun beides aktivieren. Dazu dienen zwei Optionen in der Datei »my.cnf«:

[mysqld]
log-bin
server-id=1

Die Option »log-bin« aktiviert das Logging. Die Server-ID ist nur eine Nummer, die den Server identifiziert. Die ID ist egal, muss aber eine positive Zahl sein. Nach diesen Änderungen ist der My-SQL-Server neu zu starten.

Anschließend sind die Tabellen an der Reihe: Sie müssen geschlossen sein und alle Daten, die sich im Cache befinden, müssen ebenfalls auf die Platte geschrieben werden. Wichtig ist zudem, dass Schreibzugriffe blockiert sind. Das alles erreicht folgendes Kommando am MySQL-Prompt:

flush tables with read lock;

Sehr wichtig ist ab jetzt, dass der MySQL-Client, der gerade den Schreibzugriff blockiert, aktiv bleibt. Der Schreibschutz hebt sich sonst auf - und das darf auf keinen Fall geschehen.

Snapshot anlegen

Nun gilt es, einen Snapshot der Daten auf dem Master anzulegen. Das geht einfach mit Tar, das ein komplettes Datenverzeichnis in ein Archiv packt. Im Datenverzeichnis der MySQL-Installation gelingt dies mit dem Kommando:

tar -cvf /tmp/master-snapshot.tar

Eine Kopie der Tar-Datei kommt in das Datenverzeichnis des Slave, die sich dort mit dem Kommando

tar -xvf master-snapshot.tar

entpackt. Eine weitere Kopie sollte für Notfälle in einem sicheren Verzeichnis warten oder besser auf CD bereitliegen. Mit Hilfe dieser Tar-Datei lassen sich zu einem späteren Zeitpunkt weitere Slaves anlegen, da ja nur der Datenbestand beim Start des Binary-Log für den Slave ausschlaggebend ist.

Position des Binary-Log ermitteln

Neben dem Tar-Archiv ist die aktuelle Position des Binary-Log auf dem Master wichtig, denn nur zusammen mit dieser Information lassen sich Slaves anwerfen. Die Position fördert der Show-Befehl zutage (Abbildung 2):

show master status;

In einer kleinen Datei festgehalten sollte die Position mit auf die Backup-CD. Nun sind alle wichtigen Informationen zusammen. Der Schreibschutz auf dem Master ist ebenfalls wieder gestattet und somit das Schloss vor den Tabellen nicht mehr nötig:

unlock tables;

Der Slave-Rechner ist noch mit einer eigenen Server-ID zu versorgen. Sie findet ihrem Platz in der Datei »my.cnf«. Wichtig ist, dass Master und alle Slaves unterschiedliche IDs bekommen.

[mysqld]
server-id=2

Abbildung 2: Der Show-Befehl findet die Position des Binary-Log.

Slave zum Update auffordern

Der Slave ist jetzt ebenfalls bereit, also kann das Live-Update beginnen. Dazu sind zwar mehrere Befehle nötig, aber der Admin muss sie jeweils nur ein einziges Mal am MySQL-Prompt eingeben, und zwar:

change master to
 -> MASTER_HOST=Master-Name,
 -> MASTER_USER=Slave,
 -> MASTER_PASSWORD=Passwort,
 -> MASTER_LOG_FILE=Log-File,
 -> MASTER_LOG_POS=Offset;

Der Platzhalter »Master-Name« ist einfach mit dem Rechnernamen des Masters auszutauschen. Der »Slave« steht für dem Namen des Replikations-Accounts. Als »Log-File« ist der Name des Binary-Logs aus dem Snapshot anzugeben. Im Beispiel war das »database-bin.045«. Der »Offset« schließlich entspricht der Position des Binary-Log an der Beispielstelle »14468606«.

Jetzt muss noch der Slave-Thread auf dem Slave starten. Auch dies ist nur ein Mal erforderlich. Der MySQL-Server merkt sich, dass er als Slave fungiert. Nach dem MySQL-Kommando

start slave;

nimmt der Slave direkt Kontakt mit dem Master-Server auf und holt alle Updates ab. Bei einigen MySQL-Versionen heißt das Kommando »slave start«. Wie auch immer: Das Master-Slave-System ist jetzt fertig konfiguriert.

Datenbestand synchronisieren

Funktioniert der Master-Slave-Betrieb normal, besitzt der Slave exakt die gleichen Daten wie der Master. Nach der Installation eines neuen Slave, der erst alle Daten holen muss, ist dies nicht so - die Master-Datenbank läuft schon längst wieder und füllt sich ständig. Es hängt vom Datenbestand und dem Unterschied zwischen Snapshot und aktuellem Stand ab, wie lange die erste Synchronisation dauert. Um die Prozedur nicht zu verlängern, sollte der Master erst dann Daten annehmen, wenn der Slave seine Daten komplett übernommen hat.

Dazu bekommt der Master zuerst wieder eine Schreibsperre verpasst. Anschließend sind die aktuellen Daten des Binary-Log zu ermitteln:

flush tables with read lock;
show master status;

Nun ist der Slave mit der Aktualisierung dran, was mit folgendem Select-Statement geschieht:

select master_pos_wait (Arg1,Arg2);

Das Argument »Arg1« ist der Name der Logdatei, die der Befehl »master status« ausgibt; »arg2« entspricht der Position (Abbildung 2). Der Slave synchronisiert seinen Datenbestand dann mit dem Master und erst dann, wenn er fertig ist, kommt das »select«-Statement zurück. Jetzt darf auch der Master wieder Schreibzugriffe annehmen:

unlock tables;

Passend zu »show master status« gibt es auch ein »show slave status«-Kommando (Abbildung 3), das die Position, den Account und den Namen der Logdatei ausgibt.

Abbildung 3: Auf eine Statusabfrage per Show-Befehl liefert auch der Slave die wichtigsten Daten zurück.

Auch wenn die Replikation nicht gelingen will, hinterlassen die fehlgeschlagenen Versuche immerhin Meldungen im Error-Log. Meist handelt es sich dabei um einen Vertipper bei Account-Namen oder Passwort. Das ist mit einem neuen »change master to«-Befehl leicht zu korrigieren. Geht gar nichts mehr, bringt ein »reset slave« den Slave in den Ausgangszustand zurück.

Bei Problemen mit der Synchronisation kann es helfen, das Binary-Log zurückzusetzen. Dazu dient das Kommando »reset master«. Solche Fehler erscheinen, wenn das Binary-Log aktiv ist, obwohl der Rechner nicht als Master fungiert.

Feintuning angesagt

Das vorgestellte Replikations-Setup dient nur als Basis einer individuellen MySQL-Umgebung - zu tun gibt es noch reichlich. Per SSL (Secure Socket Layer) ist die Kommunikation zwischen Master und Slaves leicht zu verschlüsslen, was deutlich höhere Sicherheit bedeutet. Falls sich mehrere Tabellen in einer Datenbank tummeln, lassen sich bestimmte Tabellen gänzlich von der Replikation ausschließen respektive einbinden. Das funktioniert auch Datenbank-übergreifend sowie mit verschiedenen kompletten Datenbanken.

Mit zwei interessanten Änderungen beim Master- und Slave-Modus wartet die MySQL-Version 4 gegenüber den 3.23-Versionen auf: Hat sich beim Master ein ernstes Problem eingenistet, wandelt sich einer der Slaves nach einem Abstimmungsverfahren zu einem Master um. Die Lastverteilung soll zudem mit Agent-Prozessen, die selbstständig Select-Anfragen an die Slaves senden, effizienter arbeiten.

Quelle: http://www.linux-magazin.de/heft_abo/ausgaben/2004/06/im_schatten_des_meisters/(offset)/4