So richten Sie die MariaDB-Master-Slave-Replikation ein

Die Replikation in MariaDB kopiert Daten von einer Datenbank in eine andere oder sogar in mehrere andere, um eine Synchronisierung zu gewährleisten – zumindest sollte sie das. Falls Sie sich jemals gefragt haben, warum Ihre Daten nicht auf allen Servern angezeigt werden oder warum Ihre Backups nicht funktionieren, hilft Ihnen dieser Leitfaden weiter. Die Einrichtung der Replikation ist nicht immer einfach, insbesondere unter CentOS 7. Richtig konfiguriert, erleichtert sie Ihnen jedoch die Arbeit erheblich und bietet Ihnen Load Balancing und Failover-Optionen ohne großen Aufwand. Nach der Einrichtung können Sie Daten auf einem primären Server erstellen oder aktualisieren, die dann automatisch an Backups oder andere Master-Server weitergegeben werden. Achten Sie darauf, die Grundlagen zu beherrschen, um typische Fehlerquellen wie Firewall-Probleme oder fehlerhafte Konfigurationen zu vermeiden. Es kann sein, dass Sie etwas ausprobieren müssen, aber dieser Leitfaden bietet einen guten Einstieg für alle, die eine ausfallsichere MariaDB-Umgebung einrichten möchten.

Wie man MariaDB-Replikationsprobleme unter CentOS 7 behebt

Master-Master-Replikation konfigurieren – Warum nicht fast immer?

Bei manchen Konfigurationen kann diese Art der flexiblen, bidirektionalen Synchronisierung komplex werden, ist aber für Hochverfügbarkeit äußerst nützlich. Im Prinzip können beide Server Lese- und Schreibvorgänge durchführen und dienen so als Backups füreinander. Entscheidend ist die korrekte Konfiguration des Binärlogs und die Zuweisung einer eindeutigen ID an jeden Server. Andernfalls gerät MariaDB schnell durcheinander – glauben Sie mir. So gehen Sie vor.

Methode 1: Beide Master-Server vorbereiten

• Öffnen Sie die Datei /etc/my.cnf auf jedem Server und fügen Sie diesen Abschnitt hinzu (einen für Master-1, dann eine andere server_id für Master-2):

#replication server_id = 1 report_host = master log_bin = /var/lib/mysql/mariadb-bin log_bin_index = /var/lib/mysql/mariadb-bin.index relay_log = /var/lib/mysql/relay-bin relay_log_index = /var/lib/mysql/relay-bin.index 

Stellen Sie sicher, dass Sie dies auch für den zweiten Server tun, ändern Sie jedoch server_id auf 2 und passen Sie report_host entsprechend an, wahrscheinlich auf seine IP-Adresse oder seinen Hostnamen.

service mariadb restart

Manchmal hilft ein Neustart, meistens jedoch ein einfacher Neustart. Danach erstellen Sie einen dedizierten Benutzer für die Replikation.

mysql -e "CREATE USER 'repl_user'@'%' IDENTIFIED BY 'somepassword';" mysql -e "GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';" 

SHOW MASTER STATUS\G

Etwa so:

File: mariadb-bin.000002 Position: 664 

Falls Ihr Master diese Informationen nicht anzeigt, sind diese Protokolle möglicherweise nicht aktiviert.Überprüfen Sie daher Ihre Konfiguration.

Methode 2: Master mithilfe von Binlog-Informationen verbinden

• Stellen Sie nun eine Verbindung zum zweiten Server her und richten Sie die Replikation so ein, dass sie auf den ersten Server verweist. Verwenden Sie dazu die Informationen aus [Link/Dokumentation] SHOW MASTER STATUS.
• Führen Sie auf dem zweiten Server Folgendes aus:

STOP SLAVE; CHANGE MASTER TO MASTER_HOST='IP_of_Master1', MASTER_USER='repl_user', MASTER_PASSWORD='somepassword', MASTER_LOG_FILE='mariadb-bin.000002', MASTER_LOG_POS=664; START SLAVE;

Dadurch wird die Replikationsverbindung hergestellt. Wiederholen Sie denselben Vorgang auf dem ersten Server, wobei Sie die Master-Informationen so ändern, dass sie auf den zweiten Server verweisen.

Wie kann man überprüfen, ob die Replikation funktioniert?

Sobald beide Server die Verbindung bestätigt haben, kann der Test durchgeführt werden. Erstellen Sie eine neue Datenbank oder Tabelle auf Master-1:

CREATE DATABASE test_replication; USE test_replication; CREATE TABLE test_table (id INT PRIMARY KEY, name VARCHAR(50));

Prüfen Sie, ob es automatisch auf Master-2 erscheint. Wundern Sie sich nicht, wenn es nicht sofort angezeigt wird – manchmal kommt es zu Replikationsverzögerungen, insbesondere bei intensiven Schreibvorgängen. Falls es nach einiger Zeit immer noch nicht da ist, überprüfen Sie Ihre Protokolle SHOW SLAVE STATUS\Gund suchen Sie nach Fehlern wie „Angehalten“ oder anderen Problemen. Meistens sind Firewall-Blockierungen die Ursache – der MariaDB-Standardport 3306 muss auf jedem Knoten geöffnet sein, damit dies zuverlässig funktioniert.

So richten Sie ein klassisches Master-Slave-System ein

Dieser Modus entspricht den meisten Anforderungen an eine Datenbanksicherung und die Verteilung der Leselast. Sie wählen einen Server als Hauptschreiber und einen oder mehrere weitere Server als schreibgeschützte Kopien. Die Konfiguration des Slave-Servers ist ähnlich: Legen Sie dieselbe Server-ID fest, aktivieren Sie die Binärprotokollierung und geben Sie den Standort des Master-Servers an. Vergessen Sie nicht, read_only=ONauf dem Slave-Server die Option zum Schutz vor versehentlichen Schreibvorgängen zu aktivieren. Es empfiehlt sich außerdem, vorab einen Datenbank-Dump zu erstellen, um die Konfiguration in der Datei my.cnf bei einem Upgrade oder der ersten Synchronisierung nicht zu beeinträchtigen.

Im Prinzip geht man folgendermaßen vor:

• Bearbeiten Sie die Datei /etc/my.cnf auf dem Slave – stellen Sie sicher, dass server_id eindeutig ist und setzen Sie log_bin.
• Starten Sie MariaDB neu und führen Sie anschließend Folgendes aus:

STOP SLAVE; CHANGE MASTER TO MASTER_HOST='IP_of_Master', MASTER_USER='repl_user', MASTER_PASSWORD='somepassword', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=664; START SLAVE;

Einige Fallstricke – wie beispielsweise das Blockieren von Port 3306 durch firewalld unter CentOS – treten häufig auf. Sie müssen den Port öffnen, wenn Sie eine externe Verbindung wünschen – denken Sie an die entsprechenden iptables-Regeln:

iptables -I INPUT -p tcp -s slave_ip --dport 3306 -j ACCEPT

Wenn Sie firewalld verwenden, sollten Sie firewalld rules in Betracht ziehen oder es zumindest während der Einrichtung vorübergehend deaktivieren (langfristig nicht empfehlenswert!).

Überprüfung, ob alles tatsächlich funktioniert

Nehmen Sie eine Änderung auf Ihrem Master vor – beispielsweise das Erstellen einer Datenbank, Hinzufügen von Tabellen oder Einfügen von Daten – und überprüfen Sie anschließend den Slave. Werden die Daten angezeigt, ist alles in Ordnung. Andernfalls SHOW SLAVE STATUS\Gzeigt Ihnen die Ausgabe die Ursache an: Fehler, Verbindungsabbrüche oder Verzögerungen. Manchmal müssen Sie den Slave neu starten oder die Berechtigungen korrigieren, insbesondere wenn die Variable „Last_Error“ gefüllt ist. Auf manchen Systemen schlägt diese Konfiguration beim ersten Mal fehl, funktioniert dann aber nach einem Neustart oder der Korrektur der Firewall-Regeln wie von Zauberhand. Das ist etwas ungewöhnlich, aber so ist CentOS eben.

Zusammenfassung

• Konfigurieren Sie my.cnf korrekt mit eindeutigen Server-IDs und Binärlog-Pfaden.
• Erstellen Sie einen dedizierten Replikationsbenutzer mit den entsprechenden Berechtigungen.
• Rufen Sie die aktuellen Binlog-Informationen von den Master-Servern ab.
• Richten Sie die CHANGE MASTER TO-Befehle sorgfältig ein und achten Sie darauf, dass sie auf die richtigen IPs und Protokolle verweisen.
• Überprüfen Sie regelmäßig den Slave-Status und beheben Sie auftretende Fehler umgehend.
• Öffnen Sie Port 3306 in Ihrer Firewall, falls externe Verbindungen nicht funktionieren.

Zusammenfassung

Die MariaDB-Replikation unter CentOS 7 kann mitunter etwas knifflig sein, insbesondere im Hinblick auf Firewalls und Konfigurationsdateien. Sind die grundlegenden Einstellungen – Server-IDs, Binärprotokolle und Benutzerberechtigungen – jedoch korrekt, arbeitet sie recht zuverlässig. Manchmal klappt es nicht gleich beim ersten Versuch, vor allem bei Firewall-Regeln oder fehlerhaften Konfigurationen. Sobald die Replikation aber funktioniert, lohnt sich der Aufwand. Rechnen Sie mit etwas Ausprobieren; mit Geduld erhalten Sie jedoch eine Einrichtung, die nicht nur Backups erstellt, sondern auch die Last verteilt und hohe Verfügbarkeit gewährleistet.