Einrichtung der asynchronen MySQL-Replikation: Eine Schritt-für-Schritt-Anleitung

MySQL-Replikation ist eine grundlegende Funktion zur Erzielung hoher Verfügbarkeit, Skalierbarkeit und robuster Backup-Strategien. Die asynchrone Replikation, der gängigste Typ, stellt sicher, dass Daten, die auf den primären Server (Master) geschrieben werden, schließlich auf einen oder mehrere sekundäre Server (Slaves) kopiert werden, ohne dass der Master auf die Bestätigung der Transaktion durch den Slave wartet.

Diese umfassende Anleitung bietet ein detailliertes, Schritt-für-Schritt-Tutorial zur Konfiguration eines standardmäßigen Master-Slave-Asynchronreplikations-Setups mit MySQL. Wir werden die notwendigen Anpassungen der Serverkonfiguration, die Benutzerverwaltung und die kritischen Schritte zur Initialisierung der Datensynchronisierung behandeln.

Voraussetzungen und Überblick

Bevor Sie mit der Konfiguration beginnen, stellen Sie sicher, dass Sie Folgendes haben:

Zwei laufende MySQL-Server (Server A: Master, Server B: Slave).
Netzwerkkonnektivität zwischen den beiden Servern (normalerweise muss TCP-Port 3306 geöffnet sein).
Root- oder Administratorzugriff zur Konfiguration beider MySQL-Instanzen und zur Änderung der my.cnf- oder my.ini-Konfigurationsdateien.

Für diese Anleitung gehen wir davon aus, dass die IP-Adresse des Master-Servers 192.168.1.100 und die IP-Adresse des Slave-Servers 192.168.1.101 lautet.

Phase 1: Konfiguration des Master-Servers

Der Master-Server muss so konfiguriert werden, dass alle Datenänderungsereignisse in einer Binärprotokolldatei aufgezeichnet werden, aus der der Slave lesen wird.

Schritt 1: Bearbeiten der Master-Konfigurationsdatei (`my.cnf`)

Suchen Sie die MySQL-Konfigurationsdatei (typischerweise /etc/mysql/my.cnf oder /etc/my.cnf) und fügen Sie die folgenden Direktiven im Abschnitt [mysqld] hinzu oder ändern Sie sie.

[mysqld]
# 1. Eindeutige ID für diesen Server (muss größer als 0 sein)
server-id=1

# 2. Binärprotokollierung aktivieren
log-bin=mysql-bin

# 3. Liste der zu replizierenden Datenbanken (optional, aber empfohlen)
# binlog-do-db=mydatabase

# 4. Optional: Sicherstellen, dass die Verbindung TCP/IP verwendet, nützlich zum Testen
# bind-address=0.0.0.0

Hinweis: Die server-id muss in der gesamten Replikationstopologie eindeutig sein.

Schritt 2: MySQL neu starten und Binärprotokollierung überprüfen

Nachdem Sie die Konfigurationsdatei gespeichert haben, starten Sie den MySQL-Dienst auf dem Master-Server neu.

# Debian/Ubuntu
sudo systemctl restart mysql
# RHEL/CentOS
sudo systemctl restart mysqld

Melden Sie sich bei der MySQL-Befehlszeilenschnittstelle an und überprüfen Sie, ob die Binärprotokollierung aktiv ist:

SHOW VARIABLES LIKE 'log_bin';
-- Der Wert sollte ON sein

Schritt 3: Replikationsbenutzer erstellen

Die Replikation erfordert ein dediziertes Benutzerkonto auf dem Master-Server mit spezifischen Berechtigungen, die der Slave zum Verbinden und Abrufen der Binärprotokolle verwendet. Stellen Sie sicher, dass dieser Benutzer eine Remote-Verbindung von der IP-Adresse des Slaves (192.168.1.101) herstellen kann.

CREATE USER 'repl_user'@'192.168.1.101' IDENTIFIED BY 'secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.101';
FLUSH PRIVILEGES;

Schritt 4: Aktuellen Master-Status aufzeichnen

Bevor wir fortfahren, müssen wir die genaue Position (Datei und Position) in der Binärprotokolldatei festlegen, von der aus der Slave mit dem Lesen beginnen soll. Dieser Schritt ist für die Synchronisierung entscheidend.

FLUSH TABLES WITH READ LOCK; -- Schreibt vorübergehend anhalten
SHOW MASTER STATUS;

-- WICHTIG: Notieren Sie sich diese beiden Werte:
-- File: mysql-bin.000001
-- Position: 1234

-- TABELLEN NICHT ENTSPERREN, WENN SIE EINEN INITIALEN SNAPSHOT ERSTELLEN (Schritt 6)

Phase 2: Konfiguration des Slave-Servers

Schritt 5: Bearbeiten der Slave-Konfigurationsdatei (`my.cnf`)

Konfigurieren Sie den Slave-Server mit einer eindeutigen ID und optionalen Einstellungen.

[mysqld]
# Eindeutige ID für diesen Server (muss sich vom Master unterscheiden)
server-id=2

# Optional: Empfohlen zur Sicherheit
read_only=1

# Optional: Relay-Protokollierung aktivieren
relay_log=mysql-relay-bin

Starten Sie den MySQL-Dienst auf dem Slave-Server nach dem Speichern der Änderungen neu.

Schritt 6: Übertragung der anfänglichen Daten (Snapshot)

Wenn der Slave-Server leer ist, müssen Sie ihn mit der aktuellen Datenstruktur und dem Inhalt des Masters bevölkern. Dieser anfängliche Snapshot muss während die Master-Tabellen gesperrt sind (aus Schritt 4) erstellt werden.

Führen Sie auf dem Master-Server den Befehl mysqldump aus. Wir verwenden die Option --master-data=2, um die notwendige CHANGE MASTER TO-Anweisung automatisch in die Dump-Datei aufzunehmen, was Schritt 7 vereinfacht.

# Auf der Master-Server-Konsole/Shell ausführen
mysqldump -u root -p --all-databases --master-data=2 --single-transaction > master_dump.sql

# Kehren Sie nun zur Master MySQL CLI zurück und heben Sie die Sperre auf
UNLOCK TABLES;

Übertragen Sie master_dump.sql auf den Slave-Server und importieren Sie es:

# Auf der Slave-Server-Konsole/Shell ausführen
mysql -u root -p < master_dump.sql

Best Practice: Die Verwendung von master-data=2 wird dringend empfohlen, da sie die Erfassung der richtigen Binärprotokollposition direkt zu Beginn des Dumps automatisiert.

Phase 3: Replikation initiieren

Schritt 7: Master-Verbindung definieren

Führen Sie auf der MySQL-Befehlszeile des Slave-Servers den Befehl CHANGE MASTER TO aus und ersetzen Sie die Werte aus Schritt 4 und den in Schritt 3 erstellten Benutzer.

CHANGE MASTER TO
    MASTER_HOST='192.168.1.100',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='secure_password',
    MASTER_LOG_FILE='mysql-bin.000001', -- Die in Schritt 4 aufgezeichnete Datei
    MASTER_LOG_POS=1234;              -- Die in Schritt 4 aufgezeichnete Position

Schritt 8: Replikation starten und verifizieren

Nachdem die Verbindungsparameter definiert wurden, starten Sie die Replikations-Threads des Slaves.

START SLAVE;

Überprüfen Sie mit dem Befehl SHOW SLAVE STATUS, ob die Replikations-Threads laufen und korrekt kommunizieren:

SHOW SLAVE STATUS\G

Untersuchen Sie die Ausgabe auf die folgenden kritischen Felder:

Feld	Erwarteter Wert	Beschreibung
`Slave_IO_Running`	`Yes`	Slave stellt erfolgreich eine Verbindung zum Master her.
`Slave_SQL_Running`	`Yes`	Slave wendet Transaktionen auf seine Datenbank an.
`Seconds_Behind_Master`	`0` oder niedrige Zahl	Zeigt die Replikationslatenz an. Sollte schnell auf 0 fallen.

Wenn entweder Slave_IO_Running oder Slave_SQL_Running No anzeigt, untersuchen Sie die Felder Last_IO_Error oder Last_SQL_Error auf Hinweise zur Fehlerbehebung (z. B. Firewall-Probleme, falsche Anmeldedaten, doppelte Schlüssel).

Tipps zur Fehlerbehebung und Wartung

Umgang mit Replikationsfehlern

Wenn der Slave auf einen Fehler stößt (z. B. beim Versuch, einen doppelten Primärschlüssel einzufügen), stoppt der Thread Slave_SQL_Running. Sie können normalerweise kleinere, nicht kritische Fehler umgehen mit:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

Warnung: Verwenden Sie SQL_SLAVE_SKIP_COUNTER mit Bedacht. Das Überspringen von Transaktionen kann zu Datenabweichungen (Inkonsistenzen) zwischen Master und Slave führen.

Konsistenz prüfen

Obwohl die asynchrone Replikation effizient ist, garantiert sie keine sofortige Konsistenz. Für kritische Umgebungen verwenden Sie Tools wie Percona Toolkit's pt-table-checksum, um regelmäßig auf Datenabweichungen zwischen Master und Slave zu prüfen.

Binärprotokolle verwalten

Binärprotokolle verbrauchen mit der Zeit Speicherplatz. Konfigurieren Sie die Ablaufzeit von Protokollen auf dem Master, um eine Überlastung der Festplatte zu verhindern:

[mysqld]
# Binärprotokolle älter als 7 Tage (604800 Sekunden) entfernen
expire_logs_days=7