mysql master-slave-Replikation 1


Bei einer Master-Slave-Replikation stehen auf dem Slave die Datenbanken des Master 1:1 zur Verfügung. Am Master ausgeführte Änderungen sind unmittelbar (oder optional auch verzögert mittels master_delay) am Slave verfügbar.
Als Backuplösung eignet sich das ganze daher nicht. Es ist so aber möglich, auf mehreren Servern die gleichen Daten zur Verfügung zu haben, die an einem zentralen Punkt (Master) verwaltet werden.

Einrichtung des Master:
/etc/my.cnf anpassen unterhalb von [mysqld] anpassen. Hierbei muss “skip-networking” kommentiert werden, da mysql sonst nur auf lokale Anfragen reagiert:

#skip-networking
#Zusätzlich brauchen wir noch Angaben für die Replikation:
server-id = 1
log-bin = mysql-bin
max_binlog_size = 500M
binlog_format = mixed
sync_binlog = 1
expire_logs_days = 5
relay-log = slave-relay.log
relay-log-index = slave-relay-log.index

Um z.B. die Datenbank nagios gleich von der Replikation auszunehmen, kann in der my.cnf
binlog-ignore-db = nagios
gesetzt werden.

Zum ignorieren einzelner Tabellen in der Replikation wird
binlog-ignore-table = DATENBANK.TABELLE verwendet.

Slave-User in mysql anlegen:

GRANT REPLICATION SLAVE ON *.* TO 'slave_user01'@'%' IDENTIFIED BY '';
FLUSH PRIVILEGES;

Nach einem Neustart von mysql ist der Master für die Replikation eingerichtet und der Slave kann sich als slave_user01 verbinden.

Als nächstes wird der Slave eingerichtet. Auch hier werden die Änderungen von [mysqld] in /etc/my.cnf eingetragen:

#skip-networking
server-id = 2
expire_logs_days = 5
max_binlog_size = 500M
# Angaben zum (anderen) Master-Server
master-connect-retry = 60
report-host = sql-slave.mydomain.de

Dann werden die Datenbanken (ich habe alle in der Replikation) auf dem Master gesichert
mysqldump --add-drop-table --master-data --quick --all-databases > dump.sql

und bspw. mit scp auf den Slave-Server kopiert:
scp dump.sql root@slave.mydomain.de:/

Auf dem Slave soll der Dump eingespielt werden. Durch –master-data sollten automatisch alle für die Replikation erforderlichen Daten mitübertragen werden. Damit der Dump aber importiert werden kann, muss erstmal der Slave gestoppt werden:

stop slave;

Import durch mysql < dump.sql

und dann
start slave;

Den Erfolg sehen wir in mysql durch
show slave status \G

Sollte der dump mit --master-data nicht zum Erfolg führen, müssen die Log-Daten per Hand gesetzt werden. Dazu ist zur Sicherung der Konsistenz ein erneuter Dump erforderlich.

Auf dem Master loggen wir uns in mysql ein und sperren alle Schreibzugriffe und notieren uns die aktuellen Daten:
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;


*************************** 1. row ***************************
File: mysql-bin.000153
Position: 506858058

Als nächstes werd in einer neuen Shell die Daten mit mysqldumpwie oben beschrieben gesichert und danach die Sperre wieder aufgehoben.
UNLOCK TABLES;

Auf dem Slave wird erst ein stop slave; ausgeführt und dann der neue Dump importiert. Danach werden die Master-Daten in mysql gesetzt. Die hier aufgeführten Werte natürlich alle durch die eigenen ersetzen.

CHANGE MASTER TO MASTER_HOST='master.mydomain.de', MASTER_USER='slave_user02', MASTER_PASSWORD='some_password', MASTER_LOG_FILE='mysql-bin.000153, MASTER_LOG_POS=506858058;

Nach einem start slave; sollte der Slave jetzt laufen. Wir können dies erneut durch show slave status \G überprüfen.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Ein Gedanke zu “mysql master-slave-Replikation