MySQL Slave einrichten und prüfen

Richte den Slave so ein, dass er sich als Replikationspartner mit dem Master verbindet, importiere das Datenbanksnapshot, konfiguriere die MASTER-Einstellungen (Host, Benutzer, Log-Datei/Position, SSL-Pfade) und starte den Slave. Prüfe SHOW SLAVE STATUS \G und achte darauf, dass Slave_IO_Running und Slave_SQL_Running beide Yes sind.

Übersicht

Dieses Dokument beschreibt Schritt für Schritt, wie Sie einen MySQL-Slave (server2) einrichten, damit er Änderungen vom Master (server1) repliziert. Es enthält Beispielkonfigurationen, die genauen SQL-Befehle, Hinweise zur SSL-Absicherung, Prüf- und Fehlerbehebungsmaßnahmen sowie Checklisten für typische Rollen.

Wichtig: Die gezeigten Pfade, IP-Adressen, Benutzer und Passwörter sind Platzhalter. Ersetzen Sie diese durch Ihre Werte.

Voraussetzungen

MySQL auf Master und Slave installiert
Replikations-Benutzer mit REPLICATION SLAVE auf dem Master angelegt
Snapshot (Dump) der Datenbank vom Master verfügbar (snapshot.sql)
Zertifikate für SSL-Verbindung vorhanden, falls SSL verwendet wird
Root-/Admin-Zugang auf beiden Servern

1. Konfiguration der my.cnf auf dem Slave

Öffnen Sie /etc/my.cnf auf server2 und stellen Sie sicher, dass die folgenden Einstellungen im [mysqld]-Abschnitt vorhanden sind. server-id muss eindeutig sein und sich vom Master unterscheiden.

server2:

vi /etc/my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Standardmäßig altes Passwortformat für Kompatibilität mit alten Clients
old_passwords=1
ssl
server-id=2
master-connect-retry=60
replicate-do-db=exampledb

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Hinweis: server-id muss numerisch und eindeutig sein (z. B. 2 auf Slave, 1 auf Master). replicate-do-db begrenzt die Replikation auf eine bestimmte Datenbank; entfernen oder anpassen, wenn Sie mehrere DBs replizieren wollen.

2. MySQL neu starten

Starten Sie MySQL neu, damit die geänderte Konfiguration geladen wird:

/etc/init.d/mysqld restart

Je nach System kann der Dienstname oder der Startbefehl abweichen (systemctl restart mysqld).

3. Leere Ziel-Datenbank erstellen und Snapshot importieren

Erstellen Sie auf server2 eine leere Datenbank mit dem gleichen Namen wie auf dem Master:

mysql -u root -p

CREATE DATABASE exampledb;
quit;

Stoppen Sie den Slave (falls vorhanden), kopieren/importieren Sie das Snapshot-File und starten Sie danach die Replikation:

/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

Dann verbinden Sie sich erneut zum MySQL-Shell:

mysql -u root -p

4. CHANGE MASTER TO konfigurieren

Führen Sie auf server2 den folgenden Befehl aus. Ersetzen Sie MASTER_HOST, MASTER_USER, MASTER_PASSWORD, MASTER_LOG_FILE und MASTER_LOG_POS mit den Werten, die Sie zuvor auf dem Master mit SHOW MASTER STATUS; erhalten haben.

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=3096416, MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/newcerts/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/newcerts/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/newcerts/client-key.pem';

Erklärungen zu den Parametern:

MASTER_HOST: IP-Adresse oder Hostname des Masters (z. B. 192.168.0.100)
MASTER_USER: Replikationsbenutzer auf dem Master
MASTER_PASSWORD: Passwort des Replikationsbenutzers
MASTER_LOG_FILE: Log-Dateiname vom SHOW MASTER STATUS auf dem Master
MASTER_LOG_POS: Log-Position vom SHOW MASTER STATUS auf dem Master
MASTER_SSL: 1 aktiviert SSL für die Verbindung
MASTER_SSL_CA: Pfad zur CA-Datei auf dem Slave
MASTER_SSL_CERT: Pfad zum Client-Zertifikat auf dem Slave
MASTER_SSL_KEY: Pfad zum privaten Schlüssel des Clients auf dem Slave

Wichtig: Wenn Sie kein SSL verwenden möchten, lassen Sie die MASTER_SSL*-Parameter weg. In Produktionsumgebungen wird SSL empfohlen.

5. Slave starten und Status prüfen

Starten Sie den Slave-Prozess:

START SLAVE;

Prüfen Sie den Status ausführlich:

SHOW SLAVE STATUS \G

Wichtig sind insbesondere die Felder Slave_IO_Running und Slave_SQL_Running. Beide müssen den Wert Yes haben. Zusätzlich sollten bei SSL-Verbindungen Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_Cert und Master_SSL_Key Werte anzeigen.

Beispielausgabe (vereinfacht, MySQL-Felder bleiben in Englisch):

mysql> SHOW SLAVE STATUS \G * 1. row * Slave_IO_State: Waiting for master to send event Master_Host: 192.168.0.100 Master_User: slave_user Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 3096416 Relay_Log_File: mysqld-relay-bin.000002 Relay_Log_Pos: 235 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: exampledb … (Ausgabe gekürzt) Seconds_Behind_Master: 0 1 row in set (0.00 sec)

Wenn Slave_IO_Running oder Slave_SQL_Running nicht Yes sind, prüfen Sie /var/log/syslog, MySQL-Error-Logs und die Konfiguration der SSL-Zertifikate sowie Benutzerrechte.

6. Testen der Replikation

Auf dem Master: Erstellen Sie einen Testeintrag in exampledb (z. B. eine Tabelle oder INSERT).
Auf dem Slave: Prüfen Sie, ob die Änderung erscheint (z. B. SELECT).

Wenn die Änderung nach kurzer Zeit nicht erscheint, prüfen Sie SHOW SLAVE STATUS \G und die Fehlerfelder Last_Error und Last_Errno.

Kriterien für erfolgreiche Replikation

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master ist 0 oder ein plausibler kleiner Wert
Replicate_Do_DB stimmt mit importierter DB überein
Keine Einträge in Last_Error

Häufige Fehler und Lösungen

Fehler: Slave_IO_Running = No
- Ursache: Netzwerk, falscher MASTER_HOST oder Port, Firewall blockiert
- Lösung: Prüfen Sie ping/telnet auf Master:3306, Firewall-Regeln, DNS
Fehler: Slave_SQL_Running = No
- Ursache: SQL-Fehler beim Abspielen von Relay-Log (z. B. fehlende Tabelle, unterschiedliche DDL)
- Lösung: SHOW SLAVE STATUS prüfen, Last_Error lesen, ggf. Relay-Log überspringen (nur wenn sicher) oder Dump neu einspielen
Fehler: SSL-Verbindungsfehler
- Ursache: Falsche Pfade oder Berechtigungen für Zertifikat/Key, Zertifikat nicht von CA signiert
- Lösung: Prüfen Sie Dateiberechtigungen, openssl verify, und ob MASTER_SSL=1 gesetzt ist
Fehler: Replikations-User verweigert
- Ursache: Benutzer ohne REPLICATION SLAVE Rechte
- Lösung: Auf Master GRANT REPLICATION SLAVE ON . TO ‘slave_user’@’slave_host’; FLUSH PRIVILEGES;

Entscheidungshilfe bei Problemen

flowchart TD
  A[Slave startet nicht] --> B{Slave_IO_Running == Yes?}
  B -- No --> C[Netzwerk/Host prüfen]
  B -- Yes --> D{Slave_SQL_Running == Yes?}
  D -- No --> E[Last_Error prüfen und Relay-Logs analysieren]
  D -- Yes --> F[Replikation läuft richtig]
  C --> G[Firewall, Port, DNS prüfen]
  E --> H[Evtl. Dump neu importieren oder Fehler gezielt beheben]

Alternative Ansätze und Erwägungen

GTID-basierte Replikation: Erleichtert Failover, verhindert Positionen-Management. Nützlich in großen Umgebungen.
Semisynchrone Replikation: Reduziert Datenverlust bei Master-Ausfall, kann jedoch Latenz erhöhen.
Multi-Source-Replikation: Ein Slave empfängt von mehreren Master-Quellen (falls benötigt).

Sicherheits- und Datenschutzhinweise

Replikation über das Netzwerk überträgt vollständige Daten. Setzen Sie SSL ein und schützen Sie Zertifikate mit restriktiven Dateiberechtigungen.
Prüfen Sie personenbezogene Daten (DSGVO). Replikation über Ländergrenzen kann rechtliche Vorgaben auslösen.
Verwenden Sie dedizierte Replikations-Benutzer mit minimalen Rechten.

Rollenspezifische Checklisten

DBA

Prüfen Sie SHOW MASTER STATUS auf dem Master und notieren Sie File/Pos.
Erstellen Sie snapshot.sql konsistent (LOCK TABLES oder mysqldump –single-transaction je nach Storage Engine).

Sysadmin

Firewall und Netzwerkverbindungen für Port 3306 prüfen
Zertifikate auf Slave bereitstellen (/etc/mysql/newcerts/*)

Security

Dateirechte auf Zertifikaten prüfen (600 für private keys)
Verschlüsselung aktivieren (MASTER_SSL=1)

Testfälle und Abnahmekriterien

Testfall 1: Einfügen eines Datensatzes auf Master -> Datensatz erscheint innerhalb 30s auf Slave
Testfall 2: SSL-Verbindung funktioniert -> Master_SSL_Allowed = Yes und Pfade gesetzt
Testfall 3: Neustart des Slave-Dienstes -> Replikation setzt sich selbständig fort

Kurzanleitung für Wiederherstellung und Rollback

Falls Relay-Logs beschädigt sind, stoppen Sie Slave, sichern Sie Relay-Logs, setzen Sie mit RESET SLAVE ALL (nur wenn neu aufsetzen gewünscht) oder verwenden Sie CHANGE MASTER TO mit neuen File/Pos.
Wenn Inkonsistenzen auftreten, erstellen Sie erneut ein konsistentes Backup vom Master und importieren Sie es auf den Slave.

Fakt-Box

Minimaler Schritt: server-id eindeutig setzen, MASTER_HOST/MASTER_USER/MASTER_LOG_FILE/MASTER_LOG_POS konfigurieren, START SLAVE
Empfohlen: SSL aktivieren, Replikations-User einschränken

Zusammenfassung

Richten Sie die my.cnf mit einer eindeutigen server-id ein, erstellen Sie eine leere Ziel-Datenbank, importieren Sie ein konsistentes Snapshot und konfigurieren Sie CHANGE MASTER TO mit den korrekten File- und Positionswerten. Starten Sie den Slave und überprüfen Sie SHOW SLAVE STATUS \G. Achten Sie auf SSL, Benutzerrechte und Log-Positionen.