So richten Sie die Replikation in MySQL ein

Einführung

Bei der Arbeit mit Datenbanken kann es nützlich sein, mehrere Kopien Ihrer Daten zu haben. Dies bietet Redundanz, falls einer der Datenbankserver ausfällt, und kann die Verfügbarkeit, Skalierbarkeit und Gesamtleistung einer Datenbank verbessern. Die Praxis, Daten über mehrere separate Datenbanken zu synchronisieren, wird Replikation genannt.

MySQL ist ein relationales Datenbankmanagementsystem und die derzeit weltweit beliebteste relationale Open-Source-Datenbank. Es wird mit einer Reihe von integrierten Replikationsfunktionen installiert, die es Ihnen ermöglichen, mehrere Kopien Ihrer Daten zu verwalten.

Dieses Tutorial beschreibt, wie Sie eine MySQL-Instanz auf einem Server als Quelldatenbank konfigurieren und dann eine MySQL-Instanz auf einem anderen Server als deren Replikat konfigurieren. Es enthält außerdem einen Überblick darüber, wie MySQL die Replikation handhabt.

Voraussetzungen

Um diese Anleitung auszuführen, benötigen Sie:

  • Zwei Server, auf denen Ubuntu 20.04 läuft. Beide sollten einen administrativen Nicht-Root-Benutzer mit sudo-Rechten und eine mit UFW konfigurierte Firewall haben. Folgen Sie unserer Anleitung zur Ersteinrichtung des Servers für Ubuntu 20.04, um beide Server einzurichten.
  • MySQL wird auf jedem Server installiert. In dieser Anleitung wird davon ausgegangen, dass Sie die neueste Version von MySQL verwenden, die in den Ubuntu-Standard-Repositories verfügbar ist, nämlich Version 8.0.25. Um diese auf beiden Servern zu installieren, folgen Sie unserer Anleitung zur Installation von MySQL auf Ubuntu 20.04.

Beachten Sie, dass die in dieser Anleitung beschriebene Vorgehensweise darin besteht, die MySQL-Installation auf einem Server als Quelldatenbank zu bestimmen und dann die MySQL-Installation auf dem anderen Server als Replikat der Quelle zu konfigurieren. Um die Übersichtlichkeit zu wahren, werden alle Befehle, die auf dem Server der Quelldatenbank ausgeführt werden müssen, blau hinterlegt, etwa so:

Ebenso werden alle Befehle, die auf dem Server der Replikat-MySQL-Instanz ausgeführt werden müssen, rot hinterlegt:

Schließlich enthält dieses Lernprogramm optionale Anweisungen zum Migrieren von Daten in einer vorhandenen Datenbank von der Quelle zum Replikat. Bei diesem Vorgang wird ein Snapshot der Quelldatenbank erstellt und die resultierende Datei auf das Replikat kopiert. Dazu empfehlen wir Ihnen, SSH-Schlüssel auf dem Quellserver einzurichten und dann sicherzustellen, dass der öffentliche Schlüssel der Quelle auf das Replikat kopiert wurde.

Verstehen der Replikation in MySQL

In MySQL beinhaltet die Replikation, dass die Quelldatenbank jede Änderung an den Daten in einer oder mehreren Datenbanken in einer speziellen Datei, dem so genannten Binärprotokoll, aufzeichnet. Sobald die Replikat-Instanz initialisiert wurde, erstellt sie zwei Thread-Prozesse.

Der erste, IO-Thread genannt, verbindet sich mit der Quell-MySQL-Instanz und liest die Binärprotokoll-Ereignisse Zeile für Zeile und kopiert sie dann in eine lokale Datei auf dem Server des Replikats, die Relay-Log genannt wird. Der zweite Thread, SQL-Thread genannt, liest die Ereignisse aus dem Relay-Log und wendet sie dann so schnell wie möglich auf die Replikat-Instanz an.

Aktuelle Versionen von MySQL unterstützen zwei Methoden zur Replikation von Daten. Der Unterschied zwischen diesen Replikationsmethoden hat damit zu tun, wie die Replikate verfolgen, welche Datenbankereignisse aus der Quelle sie bereits verarbeitet haben.

MySQL bezeichnet seine traditionelle Replikationsmethode als positionsbasierte Replikation der binären Protokolldatei. Wenn Sie eine MySQL-Instanz mit dieser Methode in ein Replikat verwandeln, müssen Sie ihr einen Satz binärer Protokollkoordinaten zur Verfügung stellen. Diese bestehen aus dem Namen der binären Protokolldatei auf der Quelle, die das Replikat lesen muss, und einer bestimmten Position innerhalb dieser Datei, die das erste Datenbankereignis darstellt, das das Replikat in seine eigene MySQL-Instanz kopieren soll.

Diese Koordinaten sind wichtig, da Replikate eine Kopie des gesamten binären Protokolls ihrer Quelle erhalten und ohne die richtigen Koordinaten damit beginnen, jedes darin aufgezeichnete Datenbankereignis zu replizieren. Dies kann zu Problemen führen, wenn Sie nur Daten nach einem bestimmten Zeitpunkt oder nur eine Teilmenge der Daten der Quelle replizieren wollen.

Die positionsbasierte Replikation von binären Protokolldateien ist für viele Anwendungsfälle praktikabel, aber diese Methode kann in komplexeren Setups unhandlich werden. Dies führte zur Entwicklung der neueren nativen Replikationsmethode von MySQL, die manchmal auch als transaktionsbasierte Replikation bezeichnet wird. Bei dieser Methode wird ein globaler Transaktionsbezeichner (GTID) für jede Transaktion – oder einen isolierten Arbeitsschritt, der von einer Datenbank ausgeführt wird – erstellt, den die Quell-MySQL-Instanz ausführt.

Die Mechanik der transaktionsbasierten Replikation ähnelt der auf binären Protokolldateien basierenden Replikation: Wann immer eine Datenbanktransaktion auf der Quelle auftritt, weist MySQL eine GTID für die Transaktion zu und zeichnet sie zusammen mit der Transaktion selbst in der binären Protokolldatei auf. Die GTID und die Transaktion werden dann an die Replikate der Quelle übertragen, damit diese sie verarbeiten können.

Die transaktionsbasierte Replikation von MySQL hat eine Reihe von Vorteilen gegenüber der traditionellen Replikationsmethode. Da sowohl eine Quelle als auch ihre Replikate die GTIDs beibehalten, wird zum Beispiel eine Transaktion übersprungen, wenn entweder die Quelle oder ein Replikat auf eine Transaktion mit einer GTID stößt, die sie bereits verarbeitet haben.

Dies trägt dazu bei, die Konsistenz zwischen der Quelle und ihren Replikaten sicherzustellen. Außerdem müssen die Replikate bei der transaktionsbasierten Replikation die binären Protokollkoordinaten des nächsten zu verarbeitenden Datenbankereignisses nicht kennen. Das bedeutet, dass das Starten neuer Replikate oder das Ändern der Reihenfolge der Replikate in einer Replikationskette weit weniger kompliziert ist.

Beachten Sie, dass dies nur eine allgemeine Erklärung ist, wie MySQL die Replikation handhabt; MySQL bietet viele Optionen, die Sie anpassen können, um Ihre eigene Replikationseinrichtung zu optimieren. Diese Anleitung beschreibt, wie Sie die positionsbasierte Replikation von binären Protokolldateien einrichten.

Wenn Sie jedoch daran interessiert sind, einen anderen Typ von Replikationsumgebung zu konfigurieren, empfehlen wir Ihnen, die offizielle Dokumentation von MySQL zu lesen.

Schritt 1 – Anpassen der Firewall Ihres Quellservers

Vorausgesetzt, Sie haben die Anleitung zur Ersteinrichtung des Servers befolgt, werden Sie auf beiden Servern eine Firewall mit UFW konfiguriert haben. Dies trägt dazu bei, dass Ihre beiden Server sicher sind, aber die Firewall des Quell-Servers blockiert alle Verbindungsversuche von Ihrer MySQL-Replikat-Instanz.

Um dies zu ändern, müssen Sie eine UFW-Regel einfügen, die Verbindungen von Ihrem Replikat durch die Firewall der Quelle zulässt. Sie können dies tun, indem Sie einen Befehl wie den folgenden auf Ihrem Quellserver ausführen.

Dieser spezielle Befehl erlaubt alle Verbindungen, die von der IP-Adresse des Replikatservers – dargestellt durch replica_server_ip – ausgehen, zur Standard-Portnummer von MySQL, 3306:

sudo ufw allow from replica_server_ip to any port 3306

Achten Sie darauf, replica_server_ip durch die tatsächliche IP-Adresse Ihres Replikationsservers zu ersetzen. Wenn die Regel erfolgreich hinzugefügt wurde, sehen Sie die folgende Ausgabe:

Output
 Rule added

Danach müssen Sie keine Änderungen an den Firewall-Regeln des Replikats vornehmen, da der Replikatserver keine eingehenden Verbindungen empfängt und die ausgehenden Verbindungen zum Quell-MySQL-Server nicht durch UFW blockiert werden. Sie können mit dem Aktualisieren der Konfiguration der Quell-MySQL-Instanz fortfahren, um die Replikation zu aktivieren.

Schritt 2 – Konfigurieren der Quelldatenbank

Damit Ihre Quell-MySQL-Datenbank mit der Replikation von Daten beginnen kann, müssen Sie einige Änderungen an ihrer Konfiguration vornehmen.

Unter Ubuntu 20.04 heißt die Standard-MySQL-Serverkonfigurationsdatei mysqld.cnf und befindet sich im Verzeichnis /etc/mysql/mysql.conf.d/. Öffnen Sie diese Datei auf dem Quellserver mit Ihrem bevorzugten Texteditor. Hier verwenden wir nano:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Suchen Sie innerhalb der Datei die Direktive bind-address. Sie sieht standardmäßig wie folgt aus:

/etc/mysql/mysql.conf.d/mysqld.cnf
 . . .
 bind-address            = 127.0.0.1
 . . .

127.0.0.1 ist eine IPv4-Loopback-Adresse, die localhost repräsentiert, und wenn Sie diesen Wert für die bind-address-Direktive festlegen, wird MySQL angewiesen, nur auf Verbindungen mit der localhost-Adresse zu warten. Mit anderen Worten: Diese MySQL-Instanz kann nur Verbindungen annehmen, die von dem Server stammen, auf dem sie installiert ist.

Denken Sie daran, dass Sie Ihre andere MySQL-Instanz in ein Replikat dieser Instanz verwandeln, so dass das Replikat in der Lage sein muss, alle neuen Daten zu lesen, die in die Quellinstallation geschrieben werden. Um dies zu ermöglichen, müssen Sie Ihre Quell-MySQL-Instanz so konfigurieren, dass sie auf Verbindungen an einer IP-Adresse lauscht, die die Replik erreichen kann, wie z. B. die öffentliche IP-Adresse des Quell-Servers.

Ersetzen Sie 127.0.0.1 durch die IP-Adresse des Quell-Servers. Danach sieht die bind-address-Direktive wie folgt aus, wobei die IP-Adresse Ihres eigenen Servers anstelle von source_server_ip steht:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
bind-address = source_server_ip
. . .

Als Nächstes suchen Sie die Direktive server-id, die einen Bezeichner definiert, den MySQL intern verwendet, um Server in einer Replikationseinrichtung zu unterscheiden.

Jeder Server in einer Replikationsumgebung, einschließlich der Quelle und aller ihrer Replikate, muss seinen eigenen eindeutigen server-id-Wert haben. Diese Direktive wird standardmäßig auskommentiert und sieht wie folgt aus:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 server-id             = 1
 . . .

Heben Sie die Kommentierung dieser Zeile auf, indem Sie das Pfundzeichen (#) entfernen. Sie können eine beliebige Zahl als Wert für diese Direktive wählen, aber denken Sie daran, dass die Zahl eindeutig sein muss und mit keiner anderen Server-ID in Ihrer Replikationsgruppe übereinstimmen darf. Der Einfachheit halber belässt das folgende Beispiel diesen Wert auf dem Standardwert 1:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 server-id               = 1
 . . .

Unterhalb der Zeile server-id finden Sie die Direktive log_bin. Diese definiert den Basisnamen und den Speicherort der binären Protokolldatei von MySQL.

Wenn sie auskommentiert ist, wie es bei dieser Direktive standardmäßig der Fall ist, ist die binäre Protokollierung deaktiviert. Ihr Replikationsserver muss die Binärprotokolldatei der Quelle lesen, damit er weiß, wann und wie er die Daten der Quelle replizieren soll, also kommentieren Sie diese Zeile aus, um die Binärprotokollierung auf der Quelle zu aktivieren. Nachdem Sie dies getan haben, wird es wie folgt aussehen:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 log_bin                       = /var/log/mysql/mysql-bin.log
 . . .

Scrollen Sie schließlich zum Ende der Datei, um die auskommentierte Direktive binlog_do_db zu finden:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 binlog_do_db          = include_database_name

Entfernen Sie das Pfundzeichen, um diese Zeile zu entkommentieren, und ersetzen Sie include_database_name durch den Namen der Datenbank, die Sie replizieren möchten. In diesem Beispiel zeigt die Direktive binlog_do_db auf eine Datenbank mit dem Namen db, aber wenn Sie eine vorhandene Datenbank in Ihrer Quelle haben, die Sie replizieren möchten, verwenden Sie deren Namen anstelle von db:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 binlog_do_db          = db

Hinweis: Wenn Sie mehr als eine Datenbank replizieren möchten, können Sie für jede Datenbank, die Sie hinzufügen möchten, eine weitere binlog_do_db-Direktive hinzufügen. In diesem Tutorial geht es weiter mit der Replikation nur einer einzigen Datenbank, aber wenn Sie mehr replizieren wollten, könnte es wie folgt aussehen:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 binlog_do_db          = db
 binlog_do_db          = db_1
 binlog_do_db          = db_2

Alternativ können Sie angeben, welche Datenbanken MySQL nicht replizieren soll, indem Sie eine binlog_ignore_db-Direktive für jede Datenbank hinzufügen:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 binlog_ignore_db          = db_to_ignore

Nachdem Sie diese Änderungen vorgenommen haben, speichern und schließen Sie die Datei. Wenn Sie nano verwendet haben, um die Datei zu bearbeiten, tun Sie dies mit STRG + X, Y und dann ENTER.

Starten Sie dann den MySQL-Dienst neu, indem Sie den folgenden Befehl ausführen:

sudo systemctl restart mysql

Damit ist diese MySQL-Instanz bereit, als Quelldatenbank zu fungieren, die Ihr anderer MySQL-Server replizieren wird. Bevor Sie Ihr Replikat konfigurieren können, müssen Sie jedoch noch ein paar weitere Schritte auf der Quelle durchführen, um sicherzustellen, dass Ihre Replikationstopologie korrekt funktioniert. Der erste davon ist das Anlegen eines dedizierten MySQL-Benutzers, der alle Aktionen im Zusammenhang mit dem Replikationsprozess durchführen wird.

Schritt 3 – Erstellen eines Replikationsbenutzers

Jedes Replikat in einer MySQL-Replikationsumgebung verbindet sich mit der Quelldatenbank mit einem Benutzernamen und einem Passwort. Die Replikate können sich mit jedem MySQL-Benutzerprofil verbinden, das auf der Quelldatenbank vorhanden ist und über die entsprechenden Berechtigungen verfügt, aber in diesem Tutorial wird beschrieben, wie Sie einen dedizierten Benutzer für diesen Zweck erstellen.

Beginnen Sie damit, die MySQL-Shell zu öffnen:

sudo mysql

Hinweis: Wenn Sie einen dedizierten MySQL-Benutzer konfiguriert haben, der sich mit einem Passwort authentifiziert, können Sie sich stattdessen mit einem Befehl wie diesem mit Ihrem MySQL verbinden:

mysql -u sammy -p

Ersetzen Sie sammy durch den Namen Ihres dedizierten Benutzers und geben Sie das Passwort dieses Benutzers ein, wenn Sie dazu aufgefordert werden.

Beachten Sie, dass einige Vorgänge in dieser Anleitung, einschließlich einiger, die auf dem Replikationsserver ausgeführt werden müssen, erweiterte Berechtigungen erfordern. Aus diesem Grund kann es bequemer sein, sich als administrativer Benutzer zu verbinden, wie Sie es mit dem vorherigen Befehl sudo mysql tun können.

Wenn Sie jedoch einen weniger privilegierten MySQL-Benutzer während dieser Anleitung verwenden möchten, sollte dieser zumindest die Berechtigungen CREATE USER, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE und REPLICATION_SLAVE_ADMIN erhalten.


Erstellen Sie an der Eingabeaufforderung einen neuen MySQL-Benutzer. Im folgenden Beispiel wird ein Benutzer mit dem Namen replica_user angelegt, aber Sie können Ihren Benutzer so nennen, wie Sie möchten. Stellen Sie sicher, dass Sie replica_server_ip in die öffentliche IP-Adresse Ihres Replikationsservers und das Passwort in ein sicheres Passwort Ihrer Wahl ändern:

mysql> CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

Beachten Sie, dass dieser Befehl angibt, dass replica_user das Authentifizierungs-Plugin mysql_native_password verwendet. Es ist möglich, stattdessen den Standard-Authentifizierungsmechanismus von MySQL, caching_sha2_password, zu verwenden, aber dies würde das Einrichten einer verschlüsselten Verbindung zwischen der Quelle und dem Replikat erfordern.

Diese Art der Einrichtung wäre optimal für Produktionsumgebungen, aber das Konfigurieren von verschlüsselten Verbindungen geht über den Rahmen dieses Tutorials hinaus. Die MySQL-Dokumentation enthält Anweisungen zum Konfigurieren einer Replikationsumgebung, die verschlüsselte Verbindungen verwendet, wenn Sie dies einrichten möchten.

Nachdem Sie den neuen Benutzer erstellt haben, erteilen Sie ihm die entsprechenden Berechtigungen. Ein MySQL-Replikationsbenutzer muss mindestens über die Berechtigungen REPLICATION SLAVE verfügen:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';

Danach ist es sinnvoll, den Befehl FLUSH PRIVILEGES auszuführen. Dadurch wird der Speicher freigegeben, den der Server als Ergebnis der vorangegangenen CREATE USER- und GRANT-Anweisungen zwischengespeichert hat:

mysql> FLUSH PRIVILEGES;

Damit haben Sie das Einrichten eines Replikationsbenutzers auf Ihrer Quell-MySQL-Instanz abgeschlossen. Beenden Sie jedoch nicht die MySQL-Shell. Lassen Sie sie vorerst geöffnet, da Sie sie im nächsten Schritt verwenden werden, um einige wichtige Informationen über die binäre Protokolldatei der Quelldatenbank zu erhalten.

Schritt 4 – Abrufen von Binärprotokollkoordinaten aus der Quelle

Sie erinnern sich aus dem Abschnitt Replikation in MySQL verstehen, dass MySQL die Replikation implementiert, indem es Datenbankereignisse aus der binären Protokolldatei der Quelle Zeile für Zeile kopiert und jedes Ereignis auf dem Replikat implementiert.

Wenn Sie die positionsbasierte Replikation der binären Protokolldatei von MySQL verwenden, müssen Sie dem Replikat einen Satz von Koordinaten zur Verfügung stellen, die den Namen der binären Protokolldatei der Quelle und eine bestimmte Position innerhalb dieser Datei enthalten. Das Replikat verwendet dann diese Koordinaten, um die Stelle in der Protokolldatei zu bestimmen, an der es mit dem Kopieren von Datenbankereignissen beginnen soll und um zu verfolgen, welche Ereignisse es bereits verarbeitet hat.

In diesem Schritt wird beschrieben, wie Sie die aktuellen binären Protokollkoordinaten der Quellinstanz erhalten, um Ihre Replikate so einzustellen, dass sie mit der Replikation von Daten ab dem neuesten Punkt in der Protokolldatei beginnen.

Um sicherzustellen, dass keine Benutzer Daten ändern, während Sie die Koordinaten abrufen, was zu Problemen führen könnte, müssen Sie die Datenbank sperren, damit keine Clients Daten lesen oder schreiben können, während Sie die Koordinaten abrufen.

Sie werden die Sperre in Kürze aufheben, aber diese Prozedur wird dazu führen, dass Ihre Datenbank eine gewisse Ausfallzeit erfährt.

Sie sollten immer noch die MySQL-Shell Ihres Quell-Servers vom Ende des vorherigen Schritts geöffnet haben. Führen Sie in der Eingabeaufforderung den folgenden Befehl aus, der alle offenen Tabellen in jeder Datenbank auf Ihrer Quellinstanz schließt und sie sperrt:

mysql> FLUSH TABLES WITH READ LOCK;

Führen Sie dann den folgenden Vorgang aus, der die aktuellen Statusinformationen für die binären Protokolldateien der Quelle zurückgibt:

mysql> SHOW MASTER STATUS;

Sie werden in Ihrer Ausgabe eine Tabelle ähnlich diesem Beispiel sehen:

Dies ist die Position, von der aus die Replikation mit dem Kopieren von Datenbankereignissen beginnt. Notieren Sie den Dateinamen und den Positionswert, da Sie diese später benötigen, wenn Sie die Replikation initiieren.

Was Sie unmittelbar nach dem Abrufen dieser Informationen tun, hängt davon ab, ob Ihre Quelldatenbank über vorhandene Daten verfügt, die Sie zu Ihren Replikaten migrieren möchten. Springen Sie zu demjenigen der beiden folgenden Unterabschnitte, der für Ihre Situation am sinnvollsten ist.

Wenn Ihre Quelle keine vorhandenen Daten zum Migrieren hat

Wenn Ihre Quell-MySQL-Instanz eine neue Installation ist oder keine vorhandenen Daten hat, die Sie in Ihre Replikate migrieren möchten, können Sie an dieser Stelle die Tabellen entsperren:

mysql> UNLOCK TABLES;

Wenn Sie dies noch nicht getan haben, können Sie die Datenbank, die Sie replizieren möchten, erstellen, während die MySQL-Shell noch geöffnet ist. In Anlehnung an das Beispiel in Schritt 2 wird mit dem folgenden Vorgang eine Datenbank mit dem Namen db erstellt:

mysql> CREATE DATABASE db;
Output
 Query OK, 1 row affected (0.01 sec)

Schließen Sie danach die MySQL-Shell:

mysql> exit

Danach können Sie mit dem nächsten Schritt fortfahren.

Wenn Ihre Quelle bereits Daten zum Migrieren hat

Wenn Sie Daten auf Ihrer Quell-MySQL-Instanz haben, die Sie auf Ihre Replikate migrieren möchten, können Sie dies tun, indem Sie mit dem Dienstprogramm mysqldump einen Snapshot der Datenbank erstellen. Allerdings sollte Ihre Datenbank derzeit noch gesperrt sein. Wenn Sie im gleichen Fenster neue Änderungen vornehmen, wird die Datenbank automatisch entsperrt. Ebenso werden die Tabellen automatisch entsperrt, wenn Sie den Client beenden.

Das Entsperren der Tabellen könnte zu Problemen führen, da dies bedeuten würde, dass Clients erneut die Daten in der Datenbank ändern könnten. Dies könnte möglicherweise zu einer Nichtübereinstimmung zwischen Ihrem Daten-Snapshot und den binären Protokollkoordinaten führen, die Sie gerade abgerufen haben.

Aus diesem Grund müssen Sie ein neues Terminalfenster oder eine neue Registerkarte auf Ihrem lokalen Rechner öffnen, damit Sie den Datenbank-Snapshot erstellen können, ohne MySQL zu entsperren.

Öffnen Sie in dem neuen Terminalfenster oder der neuen Registerkarte eine weitere SSH-Sitzung zu dem Server, der Ihre Quell-MySQL-Instanz hostet:

ssh [email protected]_server_ip

Exportieren Sie dann in der neuen Registerkarte oder dem neuen Fenster Ihre Datenbank mit mysqldump. Das folgende Beispiel erzeugt eine Dump-Datei namens db.sql aus einer Datenbank namens db, aber stellen Sie sicher, dass Sie stattdessen den Namen Ihrer eigenen Datenbank angeben. Stellen Sie außerdem sicher, dass Sie diesen Befehl in der Bash-Shell und nicht in der MySQL-Shell ausführen:

sudo mysqldump -u root db > db.sql

Anschließend können Sie dieses Terminalfenster oder diese Registerkarte schließen und zu Ihrem ersten Fenster zurückkehren, in dem die MySQL-Shell noch geöffnet sein sollte. Entsperren Sie in der MySQL-Eingabeaufforderung die Datenbanken, um sie wieder beschreibbar zu machen:

mysql> UNLOCK TABLES;

Danach können Sie die MySQL-Shell beenden:

mysql> exit

Sie können nun Ihre Snapshot-Datei an Ihren Replikatserver senden. Angenommen, Sie haben SSH-Schlüssel auf Ihrem Quellserver konfiguriert und den öffentlichen Schlüssel der Quelle zur authorized_keys-Datei Ihres Replikats hinzugefügt, können Sie dies sicher mit einem scp-Befehl wie diesem tun:

scp db.sql [email protected]_server_ip:/tmp/

Achten Sie darauf, sammy durch den Namen des administrativen Ubuntu-Benutzerprofils zu ersetzen, das Sie auf Ihrem Replikationsserver erstellt haben, und replica_server_ip durch die IP-Adresse des Replikationsservers zu ersetzen. Beachten Sie auch, dass dieser Befehl den Snapshot im Verzeichnis /tmp/ des Replikationsservers ablegt.

Nachdem Sie den Snapshot an den Replikationsserver gesendet haben, verbinden Sie sich per SSH mit ihm:

ssh [email protected]_server_ip

Öffnen Sie dann die MySQL-Shell:

sudo mysql

Erstellen Sie in der Eingabeaufforderung die neue Datenbank, die Sie von der Quelle replizieren werden:

mysql> CREATE DATABASE db;

Sie müssen keine Tabellen erstellen oder diese Datenbank mit Beispieldaten laden. Das wird alles erledigt, wenn Sie die Datenbank mit dem soeben erstellten Snapshot importieren. Beenden Sie stattdessen die MySQL-Shell:

mysql> exit

Importieren Sie dann den Datenbank-Snapshot:

sudo mysql db < /tmp/db.sql

Ihr Replikat verfügt nun über alle vorhandenen Daten aus der Quelldatenbank. Sie können den letzten Schritt dieser Anleitung ausführen, um Ihren Replikationsserver so zu konfigurieren, dass er mit der Replikation neuer Änderungen in der Quelldatenbank beginnt.

Schritt 5 – Konfigurieren der Replikatdatenbank

Alles, was noch zu tun ist, ist die Konfiguration des Replikats zu ändern, ähnlich wie Sie die der Quelle geändert haben. Öffnen Sie die MySQL-Konfigurationsdatei, mysqld.cnf, diesmal auf Ihrem Replikat-Server:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Wie bereits erwähnt, muss jede MySQL-Instanz in einem Replikations-Setup einen eindeutigen server-id-Wert haben. Suchen Sie die server-id-Direktive des Replikats, entfernen Sie das Kommentarzeichen und ändern Sie den Wert in eine beliebige positive Ganzzahl, solange er sich von dem der Quelle unterscheidet:

/etc/mysql/mysql.conf.d/mysqld.cnf

server-id               = 2

Anschließend aktualisieren Sie die Werte für log_bin und binlog_do_db so, dass sie mit den Werten übereinstimmen, die Sie in der Konfigurationsdatei des Quellrechners festgelegt haben:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 log_bin                 = /var/log/mysql/mysql-bin.log
 . . .
 binlog_do_db            = db
 . . .

Fügen Sie abschließend eine relay-log-Direktive hinzu, die den Speicherort der Relay-Protokolldatei des Replikats definiert. Fügen Sie die folgende Zeile am Ende der Konfigurationsdatei ein:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
 relay-log               = /var/log/mysql/mysql-relay-bin.log

Nachdem Sie diese Änderungen vorgenommen haben, speichern und schließen Sie die Datei. Starten Sie dann MySQL auf dem Replikat neu, um die neue Konfiguration zu implementieren:

sudo systemctl restart mysql

Nachdem Sie den mysql-Dienst neu gestartet haben, können Sie endlich mit der Replikation von Daten aus Ihrer Quelldatenbank beginnen.

Schritt 6 – Starten und Testen der Replikation

Zu diesem Zeitpunkt sind Ihre beiden MySQL-Instanzen vollständig für die Replikation konfiguriert. Um die Replikation von Daten aus Ihrer Quelle zu starten, öffnen Sie die MySQL-Shell auf Ihrem Replikationsserver:

sudo mysql

Führen Sie an der Eingabeaufforderung den folgenden Vorgang aus, der mehrere MySQL-Replikationseinstellungen gleichzeitig konfiguriert. Nach dem Ausführen dieses Befehls versucht die Instanz, sobald Sie die Replikation aktiviert haben, eine Verbindung mit der IP-Adresse nach SOURCE_HOST unter Verwendung des Benutzernamens und des Passworts nach SOURCE_USER bzw.

SOURCE_PASSWORD herzustellen. Außerdem sucht er nach einer binären Protokolldatei mit dem Namen nach SOURCE_LOG_FILE und beginnt mit dem Lesen ab der Position nach SOURCE_LOG_POS.

Achten Sie darauf, dass Sie source_server_ip durch die IP-Adresse Ihres Quell-Servers ersetzen. Ebenso sollten replica_user und password mit dem Replikationsbenutzer übereinstimmen, den Sie in Schritt 2 erstellt haben; und mysql-bin.000001 und 899 sollten die binären Protokollkoordinaten wiedergeben, die Sie in Schritt 3 erhalten haben.

Möglicherweise möchten Sie diesen Befehl in einem Texteditor eingeben, bevor Sie ihn auf Ihrem Replikationsserver ausführen, damit Sie alle relevanten Informationen leichter ersetzen können:

mysql> CHANGE REPLICATION SOURCE TO
mysql> SOURCE_HOST='source_server_ip',
mysql> SOURCE_USER='replica_user',
mysql> SOURCE_PASSWORD='password',
mysql> SOURCE_LOG_FILE='mysql-bin.000001',
mysql> SOURCE_LOG_POS=899;

Aktivieren Sie anschließend den Replikationsserver:

mysql> START REPLICA;

Wenn Sie alle Details korrekt eingegeben haben, beginnt diese Instanz mit der Replikation aller Änderungen, die an der db-Datenbank in der Quelle vorgenommen wurden.

Sie können Details über den aktuellen Status der Replikation anzeigen, indem Sie den folgenden Vorgang ausführen. Der Modifikator \G in diesem Befehl ordnet den Text neu an, um ihn besser lesbar zu machen:

mysql> SHOW REPLICA STATUS\G;

Dieser Befehl gibt eine Vielzahl von Informationen zurück, die bei der Fehlersuche hilfreich sein können:


Hinweis: Wenn Ihr Replikat ein Problem bei der Verbindung hat oder die Replikation unerwartet stoppt, kann es sein, dass ein Ereignis in der binären Protokolldatei der Quelle die Replikation verhindert. In solchen Fällen können Sie den Befehl SET GLOBAL SQL_SLAVE_SKIP_COUNTER ausführen, um eine bestimmte Anzahl von Ereignissen nach der Position der binären Protokolldatei zu überspringen, die Sie im vorherigen Befehl definiert haben. In diesem Beispiel wird nur das erste Ereignis übersprungen:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

Danach müssten Sie den Nachbau erneut starten:

mysql> START REPLICA;

Wenn Sie die Replikation jemals stoppen müssen, beachten Sie außerdem, dass Sie dies tun können, indem Sie den folgenden Vorgang auf der Replikat-Instanz ausführen:

mysql> STOP REPLICA;

Ihr Replikat repliziert nun Daten aus der Quelle. Alle Änderungen, die Sie an der Quelldatenbank vornehmen, werden auf der replizierten MySQL-Instanz wiedergegeben. Sie können dies testen, indem Sie eine Beispieltabelle in Ihrer Quelldatenbank erstellen und prüfen, ob sie erfolgreich repliziert wird.

Beginnen Sie damit, die MySQL-Shell auf Ihrem Quellcomputer zu öffnen:

sudo mysql

Wählen Sie die Datenbank aus, die Sie replizieren möchten:

mysql> USE db;

Erstellen Sie dann eine Tabelle in dieser Datenbank. Die folgende SQL-Operation erstellt eine Tabelle namens example_table mit einer Spalte namens example_column:

CREATE TABLE example_table (
example_column varchar(30)
);
Output
 Query OK, 0 rows affected (0.03 sec)

Wenn Sie möchten, können Sie auch einige Beispieldaten zu dieser Tabelle hinzufügen:

INSERT INTO example_table VALUES
('This is the first row'),
('This is the second row'),
('This is the third row');
Output
 Query OK, 3 rows affected (0.03 sec)
 Records: 3  Duplicates: 0  Warnings: 0

Nachdem Sie eine Tabelle erstellt und ihr optional einige Beispieldaten hinzugefügt haben, kehren Sie zur MySQL-Shell Ihres Replikationsservers zurück und wählen die replizierte Datenbank aus:

mysql> USE db;

Führen Sie dann die Anweisung SHOW TABLES aus, um alle Tabellen innerhalb der ausgewählten Datenbank aufzulisten:

mysql> SHOW TABLES;

Wenn die Replikation korrekt funktioniert, sehen Sie die Tabelle, die Sie gerade zur Quelle hinzugefügt haben, in der Ausgabe dieses Befehls aufgelistet:

Wenn Sie der Tabelle in der Quelle einige Beispieldaten hinzugefügt haben, können Sie außerdem mit einer Abfrage wie der folgenden überprüfen, ob diese Daten ebenfalls repliziert wurden:

mysql> SELECT * FROM example_table;

In SQL ist ein Sternchen (*) eine Abkürzung für “alle Spalten”. Diese Abfrage weist also MySQL im Wesentlichen an, jede Spalte von beispiel_tabelle zurückzugeben. Wenn die Replikation wie erwartet funktioniert, gibt diese Operation diese Daten in ihrer Ausgabe zurück:

Wenn einer dieser Vorgänge die Beispieltabelle oder die Daten, die Sie der Quelle hinzugefügt haben, nicht zurückgibt, kann es sein, dass Sie irgendwo in Ihrer Replikationskonfiguration einen Fehler haben. In solchen Fällen könnten Sie die Operation SHOW REPLICA STATUS\G ausführen, um zu versuchen, die Ursache des Problems zu finden. Zusätzlich können Sie die MySQL-Dokumentation zur Fehlerbehebung bei der Replikation konsultieren, um Vorschläge zu erhalten, wie Sie Replikationsprobleme beheben können.

Fazit

Wenn Sie dieses Lernprogramm abgeschlossen haben, haben Sie eine MySQL-Replikationsumgebung eingerichtet, die die positionsbasierte Replikationsmethode von MySQL für binäre Protokolldateien mit einer Quelle und einem Replikat verwendet. Beachten Sie jedoch, dass die in dieser Anleitung beschriebene Vorgehensweise nur eine Möglichkeit darstellt, die Replikation in MySQL zu konfigurieren.

MySQL bietet eine Reihe verschiedener Replikationsoptionen, die Sie verwenden können, um eine für Ihre Anforderungen optimierte Replikationsumgebung zu erstellen. Es gibt auch eine Reihe von Werkzeugen von Drittanbietern, wie z. B. Galera Cluster, die Sie verwenden können, um die integrierten Replikationsfunktionen von MySQL zu erweitern.