MySQL Slave konfigurieren und prüfen

Kurzfassung: Diese Anleitung zeigt Schritt für Schritt, wie Sie auf server2 einen MySQL-Slave einrichten, die my.cnf anpassen, ein leeres Ziel‑Schema erstellen, einen SQL‑Snapshot importieren, den Master per CHANGE MASTER TO definieren und die Replikation (inkl. SSL) starten und prüfen. Beenden Sie mit einer kurzen Checkliste und Troubleshooting‑Hinweisen.

Ziel und Varianten

Primary intent: MySQL Slave konfigurieren Verwandte Varianten: MySQL Replikation einrichten, Master‑Slave Replikation, Replikation mit SSL, Slave_Status prüfen, Replikations‑Fehler beheben

Vorbereitung

Sie benötigen Root‑Zugriff auf server2 und server1 (Master).
Auf server1 müssen Sie zuvor einen Replikationsbenutzer angelegt und ein konsistentes Snapshot (snapshot.sql) erstellt haben.
Merken Sie sich die Ausgabe von SHOW MASTER STATUS auf dem Master (Datei und Position).

1. my.cnf auf dem Slave anpassen

Öffnen Sie die MySQL‑Konfigurationsdatei auf server2 und stellen Sie sicher, dass die folgenden Einstellungen im [mysqld]-Abschnitt vorhanden sind. Die server-id muss eindeutig sein und sich vom Master unterscheiden:

server2:

vi /etc/mysql/my.cnf

| [...] server-id=2 master-connect-retry=60 replicate-do-db=exampledb [...] |

Wichtig: server-id muss sich vom Master unterscheiden!

2. MySQL neu starten

Starten Sie MySQL neu, damit die Konfigurationsänderungen aktiv werden:

/etc/init.d/mysql restart

3. Leere Datenbank erstellen

Bevor Sie Daten importieren, erstellen Sie auf server2 eine leere Datenbank mit dem gleichen Namen wie auf dem Master:

mysql -u root -p

CREATE DATABASE exampledb;  
quit;

4. SQL‑Dump importieren

Stoppen Sie zunächst den Slave‑Prozess lokal, wechseln Sie ins temporäre Verzeichnis und importieren Sie den Snapshot:

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

Dann verbinden Sie sich wieder mit MySQL, um die Replikationsquelle zu konfigurieren:

mysql -u root -p

5. Slave als Replikationspartner einstellen

Führen Sie auf server2 den CHANGE MASTER TO‑Befehl aus und ersetzen Sie die Werte durch die tatsächlichen Angaben aus SHOW MASTER STATUS auf dem Master:

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=106, 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';

Erläuterung der Parameter:

MASTER_HOST: IP oder Hostname des Masters (z. B. 192.168.0.100).
MASTER_USER / MASTER_PASSWORD: Replikationsbenutzer und dessen Passwort auf dem Master.
MASTER_LOG_FILE / MASTER_LOG_POS: Werte aus SHOW MASTER STATUS vom Master.
MASTER_SSL: aktiviert SSL für die Verbindung.
MASTER_SSL_CA / MASTER_SSL_CERT / MASTER_SSL_KEY: Pfade zu CA‑ und Clientzertifikaten auf dem Slave.

6. Slave starten und Status prüfen

Starten Sie die Replikation auf dem Slave:

START SLAVE;

Prüfen Sie den Replikationsstatus:

SHOW SLAVE STATUS \G

Wichtig: In der Ausgabe müssen sowohl Slave_IO_Running als auch Slave_SQL_Running auf Yes stehen. Da SSL verwendet wird, sollten auch die Felder Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_Cert und Master_SSL_Key Werte enthalten.

Beispielausgabe:

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: 106  
               Relay_Log_File: mysqld-relay-bin.000002  
                Relay_Log_Pos: 251  
        Relay_Master_Log_File: mysql-bin.000001  
             Slave_IO_Running: Yes  
           Slave_SQL_Running: Yes  
              Replicate_Do_DB: exampledb  
          Replicate_Ignore_DB:   
           Replicate_Do_Table:   
       Replicate_Ignore_Table:   
      Replicate_Wild_Do_Table:   
  Replicate_Wild_Ignore_Table:   
                   Last_Errno: 0  
                   Last_Error:   
                  Skip_Counter: 0  
          Exec_Master_Log_Pos: 106  
              Relay_Log_Space: 407  
              Until_Condition: None  
               Until_Log_File:   
                Until_Log_Pos: 0  
           Master_SSL_Allowed: Yes  
           Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem  
           Master_SSL_CA_Path:   
              Master_SSL_Cert: /etc/mysql/newcerts/client-cert.pem  
            Master_SSL_Cipher:   
               Master_SSL_Key: /etc/mysql/newcerts/client-key.pem  
        Seconds_Behind_Master: 0  
Master_SSL_Verify_Server_Cert: No  
                Last_IO_Errno: 0  
                Last_IO_Error:   
               Last_SQL_Errno: 0  
               Last_SQL_Error:   
1 row in set (0.00 sec)    
  
mysql>

Beenden Sie anschließend die MySQL‑Shell:

quit;

Herzlichen Glückwunsch — Änderungen an exampledb auf dem Master sollten nun automatisch auf server2 repliziert werden. Testen Sie die Replikation durch Einfügen oder Ändern eines Datensatzes auf dem Master.

Fehlerbehebung: typische Probleme und Hinweise

Slave_IO_Running = No oder Slave_SQL_Running = No: Prüfen Sie /var/log/syslog und die MySQL‑Fehlerlogs. Häufige Ursachen: Netzwerk, Zugriffsrechte, falsche MASTER_LOG_FILE/MASTER_LOG_POS.
SSL‑Fehler: Stellen Sie sicher, dass die Zertifikat‑Dateien lesbar sind und die Pfade korrekt angegeben wurden. Master_SSL_Verify_Server_Cert=No ist in manchen Tests üblich, aber für Produktion sollten Sie Verifikation aktivieren.
Replikation springt nicht an: Verifizieren Sie, dass der Snapshot mit der angegebenen Position/Logdatei konsistent ist.

Alternative Ansätze

GTID‑basierte Replikation (global transaction identifiers) vereinfacht Failover und Positionierung; erfordert aber Änderungen an der Master‑Konfiguration.
Asynchrone vs. semi‑synchrone Replikation: semi‑synchron erhöht Datenkonsistenz, kann aber Latenz hinzufügen.
Replikation auf Dateisystemebene (z. B. LV‑Snapshots) kann bei sehr großen Datenbanken sinnvoll sein, ersetzt aber nicht die MySQL‑Replikation.

Sicherheits‑ und Datenschutzhinweise

Nutzen Sie SSL/TLS für die Verbindung zwischen Master und Slave in produktiven Umgebungen.
Schränken Sie die Rechte des Replikationsbenutzers strikt ein (nur REPLICATION SLAVE / REPLICATION CLIENT).
Prüfen Sie, ob personenbezogene Daten repliziert werden; für EU‑Daten gelten ggf. DSGVO‑Pflichten (Zugriffsprotokollierung, Datenminimierung).

Rolle‑basierte Checkliste

DBA:
- my.cnf prüfen und server-id setzen
- SSL‑Zertifikate bereitstellen
- MASTER_LOG_FILE/MASTER_LOG_POS vom Master notieren
Systemadmin:
- Firewall/Netzwerk zwischen Master und Slave prüfen
- Dateisystem‑Berechtigungen für Zertifikate setzen
Entwickler / Tester:
- Testdaten auf Master einspielen und Replikation prüfen
- Verifikation von konsistenten Daten

Kriterien für erfolgreiche Einrichtung

Beide Flags Slave_IO_Running und Slave_SQL_Running zeigen Yes.
Seconds_Behind_Master ist 0 oder ein geringer, stabiler Wert.
Keine Fehler in Last_IO_Error und Last_SQL_Error.
Änderungen im Master‑Schema werden zeitnah im Slave sichtbar.

Kurze Methodik (Mini‑Methodology)

Vorbereitung: Backup und Master‑Status erfassen.
Konfiguration: my.cnf anpassen und MySQL neu starten.
Snapshot importieren: leeres Schema erstellen und Daten einspielen.
Konnektoren konfigurieren: CHANGE MASTER TO mit SSL und Starten.
Validierung: SHOW SLAVE STATUS prüfen und Testdaten replizieren.

Zusammenfassung

Sie haben gelernt, wie man auf server2 MySQL‑Replikation einrichtet, inklusive SSL‑Konfiguration und Prüfungen. Verwenden Sie die Checkliste und Troubleshooting‑Schritte, um häufige Fehler zu beheben.