So konfigurieren Sie MySQL-Gruppenreplikation unter Ubuntu 20.04

Einführung

Die MySQL-Replikation spiegelt zuverlässig die Daten und Operationen von einer Datenbank auf eine andere. Herkömmliche Replikation umfasst einen Primärserver, der so konfiguriert ist, dass er Datenbank-Schreiboperationen akzeptiert, sowie Sekundärserver, die Aktionen aus dem Transaktionsprotokoll des Primärservers kopieren und auf ihre eigenen Datensätze anwenden. Diese Sekundärserver können für Lesezugriffe verwendet werden, sind jedoch normalerweise nicht in der Lage, Schreiboperationen durchzuführen.

Gruppenreplikation ist eine Möglichkeit zur Implementierung eines flexibleren, fehlertoleranten Replikationsmechanismus. Dabei wird ein Pool von Servern eingerichtet, die jeweils dafür verantwortlich sind, sicherzustellen, dass die Daten korrekt kopiert werden. Wenn der Primärserver Probleme hat, können Mitgliedswahlen einen neuen Primärserver aus der Gruppe auswählen. Dadurch können die verbleibenden Knoten auch bei Problemen weiterhin betrieben werden. Die Mitgliedschaftsverhandlung, die Fehlererkennung und die Nachrichtenzustellung erfolgen über eine Implementierung des Paxos-Konsensalgorithmus.

In diesem Tutorial richten Sie die MySQL-Gruppenreplikation mit einem Satz von drei Ubuntu 20.04-Servern ein. Beachten Sie, dass drei die minimale Anzahl von MySQL-Instanzen ist, die Sie bereitstellen müssen, um Gruppenreplikation in MySQL durchzuführen, während neun die maximale Anzahl ist. Während Sie dieses Tutorial durchgehen, haben Sie die Möglichkeit, die Gruppe entweder als Single-Primary- oder Multi-Primary-Replikationsgruppe einzurichten.

Voraussetzungen

Um diesen Leitfaden abzuschließen, benötigen Sie:

• Drei Server, die Ubuntu 20.04 ausführen. Jeder sollte einen nicht-root-administrativen Benutzer mit sudo-Berechtigungen und eine Firewall mit UFW konfiguriert haben. Befolgen Sie unsere Anleitung zur erstmaligen Einrichtung von Servern für Ubuntu 20.04, um jeden Server einzurichten.
• MySQL ist auf jedem Server installiert. Diese Anleitung geht davon aus, dass Sie die neueste Version von MySQL verwenden, die in den Standard-Ubuntu-Repositories verfügbar ist, was zum Zeitpunkt dieser Schreibweise Version 8.0.28 ist. Um dies auf all Ihren Servern zu installieren, folgen Sie unserer Anleitung zu Installation von MySQL unter Ubuntu 20.04 für jede Maschine.

Um die Dinge klar zu halten, bezieht sich diese Anleitung auf die drei Server als member1, member2 und member3. In den Beispielen in dieser Anleitung haben diese Mitglieder die folgenden IP-Adressen:

Jegliche Befehle, die auf member1 ausgeführt werden müssen, haben einen blauen Hintergrund, wie folgt:

Ebenso haben jegliche Befehle, die auf member2 ausgeführt werden müssen, einen roten Hintergrund:

Und jegliche Befehle, die auf member3 ausgeführt werden müssen, haben einen grünen Hintergrund:

Zuletzt haben jegliche Befehle, die auf jedem der drei Server ausgeführt werden müssen, einen standardmäßigen Hintergrund:

Schritt 1 — Generieren einer UUID zur Identifizierung der MySQL-Gruppe

Bevor Sie die MySQL-Konfigurationsdatei öffnen, um die Gruppenreplikationseinstellungen zu konfigurieren, müssen Sie eine UUID generieren, die Sie zur Identifizierung der MySQL-Gruppe verwenden können, die Sie erstellen werden.

Auf member1 verwenden Sie das uuidgen-Befehl, um eine gültige UUID für die Gruppe zu generieren:

uuidgen

Output
168dcb64-7cce-473a-b338-6501f305e561

Kopieren Sie den Wert, den Sie erhalten, da Sie ihn in einem Moment referenzieren müssen, wenn Sie einen Gruppennamen für Ihren Pool von Servern konfigurieren.

Schritt 2 — Einrichten der Gruppenreplikation in der MySQL-Konfigurationsdatei

Jetzt sind Sie bereit, die Konfigurationsdatei von MySQL zu ändern. Öffnen Sie die Hauptkonfigurationsdatei von MySQL auf jedem MySQL-Server mit Ihrem bevorzugten Texteditor. Hier verwenden wir nano:

sudo nano /etc/mysql/my.cnf

Auf Ubuntu ist MySQL mit einer Reihe verschiedener Dateien installiert, die Sie verwenden können, um verschiedene Konfigurationsänderungen zu definieren. Standardmäßig wird die my.cnf-Datei nur verwendet, um zusätzliche Dateien aus Unterverzeichnissen einzubinden. Sie müssen Ihre eigene Konfiguration unter den !includedir-Zeilen hinzufügen. Dadurch können Sie Einstellungen aus den eingebundenen Dateien überschreiben.

Um zu beginnen, starten Sie einen neuen Abschnitt, indem Sie einen [mysqld]-Header einfügen und dann die Einstellungen hinzufügen, die Sie benötigen, um die Gruppenreplikation zu aktivieren, wie im folgenden Beispiel hervorgehoben. Beachten Sie, dass diese Einstellungen von den minimalen Einstellungen für die Gruppenreplikation abweichen, die in der offiziellen MySQL-Dokumentation beschrieben sind. Das Präfix loose- ermöglicht es MySQL, Optionen, die es nicht erkennt, gnädig und ohne Fehler zu behandeln. Sie müssen einige dieser Einstellungen in Kürze ausfüllen und anpassen:

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id = 
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

Um alle diese Konfigurationsoptionen klarer zu erklären, wurden sie in die folgenden Unterabschnitte unterteilt. Bitte lesen Sie sie sorgfältig durch, da einige Abschnitte Ihnen Auswahlmöglichkeiten für die Bereitstellung Ihrer Replikationsgruppe bieten oder Sie dazu auffordern, Details einzugeben, die spezifisch für Ihre eigene Konfiguration sind.

Grundlegende Einstellungen für die Gruppenreplikation

Der erste Abschnitt enthält allgemeine Einstellungen, die für die Gruppenreplikation erforderlich sind und keine Änderung erfordern:

. . .
# Allgemeine Replikationseinstellungen
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

Eine besondere Anforderung für die Gruppenreplikation in MySQL ist, dass die Daten im InnoDB-Speicher-Engine gespeichert werden müssen. Die MySQL-Dokumentation empfiehlt ausdrücklich, die Verwendung anderer Speicher-Engines zu deaktivieren, die Fehler verursachen könnten, ähnlich wie die erste nicht auskommentierte Zeile in diesem Abschnitt.

Die verbleibenden Einstellungen aktivieren globale Transaktions-IDs, konfigurieren das binäre Protokollieren, das für die Gruppenreplikation erforderlich ist, und konfigurieren SSL für die Gruppe. Diese Konfiguration richtet auch einige andere Elemente ein, die bei der Wiederherstellung und beim Bootstrapping helfen. Sie müssen in diesem Abschnitt nichts ändern, und er sollte auf allen drei Ihrer Server identisch sein, sodass Sie nach dem Hinzufügen fortfahren können.

Gemeinsame Gruppenreplikationseinstellungen

Der zweite Abschnitt richtet gemeinsame Einstellungen für die Gruppe ein. Sie müssen dies einmal anpassen und dann dieselben Einstellungen auf jedem Ihrer Knoten verwenden. Speziell müssen Sie die UUID der Gruppe (die Sie im vorherigen Schritt erstellt haben), eine Liste autorisierter Gruppenmitglieder und die Seed-Mitglieder hinzufügen, um die anfänglichen Daten beim Beitritt zur Gruppe zu erhalten.

Setzen Sie den loose-group_replication_group_name auf den zuvor mit dem uuidgen-Befehl generierten UUID-Wert. Stellen Sie sicher, dass Sie die UUID zwischen das leere Paar doppelter Anführungszeichen setzen.

Als nächstes setzen Sie loose-group_replication_ip_whitelist auf eine Liste aller IP-Adressen Ihrer MySQL-Server, getrennt durch Kommata. Die Einstellung loose-group_replication_group_seeds sollte fast identisch mit der Whitelist sein, jedoch sollte jedem Mitglied ein bestimmter Gruppenreplikationsport angehängt werden. Verwenden Sie für diese Anleitung den empfohlenen Gruppenreplikationsport 33061:

. . .
# Gemeinsame Replikationsgruppenkonfiguration
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

Dieser Abschnitt sollte auf jedem Ihrer MySQL-Server gleich sein. Stellen Sie daher sicher, dass Sie ihn sorgfältig auf jedem kopieren.

Auswahl von Single-Primary oder Multi-Primary

Als nächstes müssen Sie entscheiden, ob Sie eine Single-Primary– oder Multi-Primary-Gruppe konfigurieren möchten. In einer Single-Primary-Konfiguration weist MySQL einem einzigen Primärserver (fast immer dem ersten Gruppenmitglied) die Bearbeitung von Schreibvorgängen zu. Eine Multi-Primary-Gruppe ermöglicht es jedem Gruppenmitglied, Schreibvorgänge durchzuführen.

Wenn Sie eine Multi-Primärgruppe konfigurieren möchten, kommentieren Sie die loose-group_replication_single_primary_mode– und loose-group_replication_enforce_update_everywhere_checks-Direktiven aus. Dadurch wird eine Multi-Primärgruppe eingerichtet. Für eine einzelne Primärgruppe lassen Sie einfach diese beiden Zeilen auskommentiert:

. . .
# Einzel- oder Multi-Primärmodus? Kommentieren Sie diese beiden Zeilen
# für den Multi-Primärmodus aus, in dem jeder Host Schreibzugriffe akzeptieren kann
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

Diese Einstellungen müssen auf jedem Ihrer MySQL-Server identisch sein.

Sie können diese Einstellung später ändern, aber nachdem Sie dies getan haben, müssen Sie jedes Mitglied Ihrer MySQL-Gruppe neu starten. Um zur neuen Konfiguration zu wechseln, müssen Sie jede der MySQL-Instanzen in der Gruppe stoppen, jedes Mitglied mit den neuen Einstellungen starten und dann die Gruppenreplikation neu booten. Dies hat keine Auswirkungen auf Ihre Daten, erfordert jedoch ein kleines Zeitfenster für Ausfallzeiten.

Hostspezifische Konfigurationseinstellungen

Der vierte Abschnitt enthält Einstellungen, die auf jedem der Server unterschiedlich sind, einschließlich:

• Die Server-ID
• Die Adresse zum Binden
• Die Adresse zum Melden an andere Mitglieder
• Die lokale Replikationsadresse und der Listening-Port

Die server_id-Anweisung muss auf eine eindeutige Nummer gesetzt werden. Für das erste Mitglied setzen Sie dies auf 1 und erhöhen Sie die Nummer für jeden zusätzlichen Host. Setzen Sie bind-address und report_host auf die jeweilige IP-Adresse des Servers, damit die MySQL-Instanz auf externe Verbindungen hört und ihre Adresse korrekt an andere Hosts meldet. Die loose-group_replication_local_address sollte ebenfalls auf die aktuelle IP-Adresse des Servers mit dem Gruppenreplikationsport (33061) gesetzt werden, der an die IP-Adresse angehängt wird.

Als Beispiel hierfür ist hier dieser Teil der Konfiguration für member1 unter Verwendung seiner Beispielp-Adresse:

. . .
# Host-spezifische Replikationskonfiguration
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

Führen Sie diesen Vorgang auf jedem Ihrer MySQL-Server durch. Hier ist die Konfiguration für member2:

. . .
# Host-spezifische Replikationskonfiguration
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"

Und hier ist die Konfiguration für member3:

. . .
# Host-spezifische Replikationskonfiguration
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"

Vergewissern Sie sich, dass Sie jede markierte IP-Adresse auf die des Servers aktualisieren, dessen Konfiguration Sie bearbeiten.

Wenn Sie fertig sind, überprüfen Sie doppelt, dass die gemeinsamen Replikationseinstellungen auf jedem Host gleich sind und dass die hostspezifischen Einstellungen für jeden Host angepasst sind. Speichern und schließen Sie die Datei auf jedem Host, wenn Sie fertig sind. Wenn Sie nano zum Bearbeiten der Datei verwendet haben, können Sie dies tun, indem Sie CTRL + X, Y und dann ENTER drücken.

Jede Ihrer Server-MYSQL-Konfigurationsdateien enthält nun die erforderlichen Direktiven zum Starten der MySQL-Gruppenreplikation. Um die neuen Einstellungen auf die MySQL-Instanz anzuwenden, starten Sie den Dienst auf jedem Ihrer Server mit dem folgenden Befehl neu:

sudo systemctl restart mysql

Mit diesem Schritt können Sie fortfahren und den Remotezugriff aktivieren, indem Sie die Firewallregeln für jeden Ihrer Server aktualisieren.

Schritt 3 – Aktualisierung der UFW-Regeln für jeden Server

Angenommen, Sie haben dem vorherigen Anleitung zum Einrichten des Servers gefolgt, dann haben Sie eine Firewall auf jedem der Server eingerichtet, auf denen Sie MySQL installiert haben, und den Zugriff für das OpenSSH UFW-Profil aktiviert. Dies ist eine wichtige Sicherheitsmaßnahme, da diese Firewalls derzeit Verbindungen zu jedem Port auf Ihren Servern blockieren, außer zu ssh-Verbindungen, die Schlüssel vorlegen, die mit denen in der jeweiligen authorized_keys-Datei jedes Servers übereinstimmen.

In der MySQL-Konfigurationsdatei haben Sie den Dienst so konfiguriert, dass er auf dem Standardport 3306 auf externe Verbindungen lauscht. Sie haben auch 33061 als Port definiert, den Mitglieder für die Replikationskoordination verwenden sollen.

Auf jedem Ihrer Mitgliedsserver müssen Sie den Zugriff auf beide dieser Ports für die anderen Mitglieder in dieser Gruppe öffnen, damit sie miteinander kommunizieren können. Um den Zugriff auf diese Ports auf Member1 für Member2 zu öffnen, führen Sie die folgenden ufw-Befehle auf Member1 aus:

sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Stellen Sie sicher, dass Sie member2_server_ip ändern, um die tatsächliche IP-Adresse Ihres Member2-Servers widerzuspiegeln. Führen Sie dann die folgenden Befehle aus, um die gleichen Ports für Member3 zu öffnen:

sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Aktualisieren Sie als Nächstes die Firewall-Regeln für Ihre anderen beiden Server. Führen Sie die folgenden Befehle auf Member2 aus und achten Sie darauf, die IP-Adressen entsprechend zu ändern, um diejenigen von Member1 und Member3 widerzuspiegeln:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Führen Sie schließlich diese beiden Befehle auf Member3 aus. Achten Sie erneut darauf, dass Sie die korrekten IP-Adressen für jeden Server eingeben:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Nachdem Sie diese UFW-Regeln hinzugefügt haben, haben alle drei Ihrer MySQL-Instanzen Zugriff auf die von MySQL auf den anderen beiden Servern verwendeten Ports.

Mit Zugriff auf die MySQL-Ports können Sie nun einen Replikationsbenutzer erstellen und das Gruppenreplikationsplugin aktivieren.

Schritt 4 — Konfigurieren von Replikationsbenutzern und Aktivieren des Gruppenreplikationsplugins

Um Verbindungen mit den anderen Servern in der Replikationsgruppe herzustellen, muss jede MySQL-Instanz einen dedizierten Replikationsbenutzer haben.

An jedem Ihrer MySQL-Server melden Sie sich mit dem administrativen Benutzer in Ihrer MySQL-Instanz an, um eine interaktive Sitzung zu starten:

sudo mysql

Weil jeder Server seinen eigenen Replikationsbenutzer haben wird, müssen Sie während des Erstellungsprozesses die binäre Protokollierung deaktivieren. Andernfalls würde die Gruppe nach Beginn der Replikation versuchen, den Replikationsbenutzer vom Primärserver auf die anderen Server zu propagieren und dabei einen Konflikt mit dem bereits vorhandenen Replikationsbenutzer zu erzeugen. Führen Sie den folgenden Befehl vom MySQL-Prompt auf jedem Ihrer Server aus:

SET SQL_LOG_BIN=0;

Nun können Sie eine CREATE USER-Anweisung ausführen, um Ihren Replikationsbenutzer zu erstellen. Führen Sie den folgenden Befehl aus, der einen Benutzer mit dem Namen repl erstellt. Diese Anweisung legt fest, dass der Replikationsbenutzer eine Verbindung über SSL herstellen muss. Verwenden Sie außerdem ein sicheres Passwort anstelle von Passwort, wenn Sie diesen Replikationsbenutzer erstellen:

CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;

Anschließend erteilen Sie dem neuen Benutzer Replikationsrechte auf dem Server:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

Dann aktualisieren Sie die Berechtigungen, um die Änderungen zu implementieren:

FLUSH PRIVILEGES;

Danach aktivieren Sie die binäre Protokollierung wieder, um den normalen Betrieb fortzusetzen:

SET SQL_LOG_BIN=1;

Als Nächstes setzen Sie den Kanal group_replication_recovery so, dass Ihr neuer Replikationsbenutzer und sein zugehöriges Passwort verwendet werden. Jeder Server wird dann diese Anmeldeinformationen zur Authentifizierung in der Gruppe verwenden:

CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

Wenn der Replikationsbenutzer vorhanden ist, können Sie das group_replication-Plugin aktivieren, um die Gruppe vorzubereiten:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Überprüfen Sie, ob das Plugin aktiv ist, indem Sie den folgenden Befehl ausführen:

SHOW PLUGINS;

Das group_replication-Plugin wird am Ende der Liste erscheinen, da es das zuletzt hinzugefügte Plugin ist:

Output
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

Dieser Ausgabebestätigt, dass das Plugin geladen wurde und derzeit aktiv ist. Bevor Sie mit dem nächsten Schritt fortfahren, stellen Sie sicher, dass Sie jeden Befehl in diesem Abschnitt auf jeder Ihrer MySQL-Instanzen ausgeführt haben.

Schritt 5 — Starten der Gruppenreplikation

Jetzt, da für jeden MySQL-Server ein Replikationsbenutzer konfiguriert ist und das Gruppenreplikations-Plugin aktiviert ist, können Sie Ihre Gruppe starten.

Starten des ersten Knotens

Um die Gruppe zu starten, führen Sie die folgenden Schritte an einem einzelnen Mitglied der Gruppe aus. Zu Demonstrationszwecken werden diese Schritte in diesem Handbuch auf member1 ausgeführt.

Gruppenmitglieder verlassen sich bei ihrem Beitritt zur Gruppe auf bestehende Mitglieder, um Replikationsdaten, aktuelle Mitgliederlisten und andere Informationen zu senden. Aus diesem Grund müssen Sie ein leicht abweichendes Verfahren verwenden, um das anfängliche Gruppenmitglied zu starten, damit es nicht erwartet, diese Informationen von anderen Mitgliedern in seiner Startliste zu erhalten.

Wenn festgelegt, informiert die Variable group_replication_bootstrap_group ein Mitglied darüber, dass es nicht erwarten sollte, Informationen von Peers zu erhalten, sondern stattdessen eine neue Gruppe gründen und sich selbst zum primären Mitglied wählen sollte. Sie können diese Variable mit folgendem Befehl aktivieren:

SET GLOBAL group_replication_bootstrap_group=ON;

Dann können Sie die Replikation für das anfängliche Gruppenmitglied starten:

START GROUP_REPLICATION;

Anschließend können Sie die Variable group_replication_bootstrap_group wieder auf OFF setzen, da die einzige Situation, in der dies angemessen ist, darin besteht, dass keine vorhandenen Gruppenmitglieder vorhanden sind:

SET GLOBAL group_replication_bootstrap_group=OFF;

Die Gruppe wird mit diesem Server als einzigem Mitglied gestartet. Überprüfen Sie dies, indem Sie die Einträge in der Tabelle replication_group_members in der Datenbank performance_schema überprüfen:

SELECT * FROM performance_schema.replication_group_members;

Diese Abfrage liefert eine einzelne Zeile, die den aktuellen Host repräsentiert:

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.00 sec)

Der Wert ONLINE für MEMBER_STATE zeigt an, dass dieser Knoten vollständig innerhalb der Gruppe betriebsbereit ist.

Erstellen Sie als nächstes eine Testdatenbank und Tabelle mit einigen Beispieldaten. Sobald weitere Mitglieder zu dieser Gruppe hinzugefügt werden, werden diese Daten automatisch an sie repliziert.

Beginnen Sie damit, eine Beispieldatenbank mit dem Namen playground zu erstellen:

CREATE DATABASE playground;

Als nächstes erstellen Sie eine Beispiel-Tabelle namens ausrüstung innerhalb der Datenbank spielplatz mit dem folgenden Befehl:

CREATE TABLE playground.equipment ( 
id INT NOT NULL AUTO_INCREMENT,
type VARCHAR(50),
quant INT,
color VARCHAR(25),
PRIMARY KEY(id)
);

Diese Tabelle enthält die folgenden vier Spalten:

• id: Diese Spalte wird Ganzzahlen enthalten, die automatisch inkrementiert werden, das bedeutet, dass Sie beim Laden der Tabelle mit Beispieldaten keine Werte für diese Spalte angeben müssen
• typ: Diese Spalte wird Zeichenfolgenwerte enthalten, die beschreiben, um welche Art von Spielplatzausrüstung es sich in der Zeile handelt
• quant: Diese Spalte wird Ganzzahlenwerte enthalten, um die Anzahl der jeweiligen Art von Spielplatzgeräten darzustellen
• farbe: Diese Spalte wird Zeichenfolgenwerte enthalten, die die Farbe der jeweiligen Ausrüstung angeben

Außerdem ist zu beachten, dass die Spalte id als Primärschlüssel dieser Tabelle festgelegt ist. In MySQL muss jede Tabelle, die in eine Gruppe repliziert wird, eine Spalte haben, die als Primärschlüssel der Tabelle festgelegt ist.

Zuletzt führen Sie den folgenden Befehl aus, um eine Zeile Daten in die Tabelle einzufügen:

INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

Abfragen Sie die Tabelle, um sicherzustellen, dass die Daten korrekt eingegeben wurden:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

Nachdem überprüft wurde, dass dieser Server Mitglied der Gruppe ist und über Schreibberechtigungen verfügt, können die anderen Server der Gruppe beitreten.

Starten der verbleibenden Knoten

Als nächstes starten Sie die Gruppenreplikation auf Member2. Da Sie bereits ein aktives Mitglied haben, müssen Sie die Gruppe nicht neu starten und dieses Mitglied kann sofort beitreten:

START GROUP_REPLICATION;

Auf Member3 starten Sie die Gruppenreplikation auf dieselbe Weise:

START GROUP_REPLICATION;

Überprüfen Sie die Mitgliederliste erneut auf einem der drei Server. Dieses Mal werden drei Server in der Ausgabe aufgeführt:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

Alle Mitglieder sollten einen MEMBER_STATE-Wert von ONLINE haben. Für eine neue Gruppe ist es ein Hinweis auf einen Fehler oder eine falsche Konfiguration, wenn eines der Knoten für mehr als einige Sekunden als RECOVERING aufgeführt ist. Überprüfen Sie die Protokolle unter /var/log/mysql/error.log, um weitere Informationen darüber zu erhalten, was schief gelaufen ist.

Als nächstes überprüfen Sie, ob die Informationen der Testdatenbank auf den neuen Mitgliedern repliziert wurden:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

Wenn die Daten auf den neuen Mitgliedern verfügbar sind, bedeutet dies, dass die Gruppenreplikation korrekt funktioniert.

Schritt 6 — Testen der Schreibfähigkeiten der neuen Gruppenmitglieder

Als nächstes können Sie versuchen, in die Datenbank von Ihren neuen Replikationsgruppenmitgliedern zu schreiben. Ob dies erfolgreich ist oder nicht, hängt davon ab, ob Sie eine einzelne primäre oder eine multi-primäre Gruppe konfiguriert haben.

Testen von Schreibvorgängen in einer einzigen primären Umgebung

In einer einzelnen primären Gruppe sollten Sie erwarten, dass alle Schreibvorgänge von einem Nicht-Primärserver aus konsistenzgründen abgelehnt werden. Sie können den aktuellen Primärserver jederzeit ermitteln, indem Sie die folgende Abfrage auf einem beliebigen Mitglied Ihrer Replikationsgruppe ausführen:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

Der Wert der Abfrage wird eine MEMBER_ID sein, die Sie durch Abfragen der Gruppenmitgliederliste wie zuvor mit einem Host abgleichen können:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Wie dieses Beispielausgabe zeigt, ist der Host unter 203.0.113.1 – Member1 – derzeit der Primärserver. Wenn Sie versuchen, in die Datenbank von einem anderen Mitglied aus zu schreiben, wird der Vorgang fehlschlagen:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

Dies ist zu erwarten, da die Gruppe derzeit mit einem einzelnen schreibfähigen Primärserver konfiguriert ist. Wenn der Primärserver Probleme hat und die Gruppe verlässt, wird die Gruppe automatisch ein neues Mitglied wählen, um der Primärserver zu sein und Schreibvorgänge anzunehmen.

Testen von Schreibvorgängen in einer Multi-Primär-Umgebung

Für Gruppen, die in einer Multi-Primär-Orientierung konfiguriert wurden, sollte jedes Mitglied in der Lage sein, Schreibvorgänge in die Datenbank zu übernehmen.

Sie können überprüfen, ob Ihre Gruppe im Multi-Primär-Modus arbeitet, indem Sie den Wert der Variablen group_replication_primary_member erneut überprüfen:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

Wenn die Variable leer ist, bedeutet dies, dass kein bestimmter Primärhost vorhanden ist und dass jedes Mitglied Schreibvorgänge akzeptieren sollte.

Überprüfen Sie dies auf member2, indem Sie versuchen, einige Daten in die Tabelle equipment zu schreiben:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
Query OK, 1 row affected (0.00 sec)

member2 hat die Schreiboperation ohne Fehler abgeschlossen.

Führen Sie auf member3 die folgende Abfrage aus, um zu überprüfen, ob das neue Element hinzugefügt wurde:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

Dies bestätigt, dass die Schreiboperation von member2 erfolgreich repliziert wurde.

Testen Sie nun die Schreibfähigkeiten auf member3, indem Sie die folgende INSERT-Anweisung ausführen:

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");

Output
Query OK, 1 row affected (0.02 sec)

Gehen Sie zurück zu member1, um sicherzustellen, dass die Schreibvorgänge von beiden neuen Mitgliedern repliziert wurden:

SELECT * FROM playground.equipment;

Output
+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

Dies bestätigt, dass die Replikation in jede Richtung funktioniert und jedes Mitglied in der Lage ist, Schreibvorgänge durchzuführen.

Schritt 7 — Die Gruppe wieder hochfahren

Sobald die Gruppe gestartet ist, können einzelne Mitglieder beitreten und austreten, ohne die Verfügbarkeit zu beeinträchtigen, solange genügend Mitglieder vorhanden sind, um primäre Server zu wählen. Wenn jedoch bestimmte Konfigurationsänderungen vorgenommen werden (wie der Wechsel zwischen Einzel- und Mehrprimärumgebungen) oder alle Mitglieder der Gruppe austreten, müssen Sie die Gruppe möglicherweise auf die gleiche Weise neu starten wie zu Beginn.

Auf member1 setzen Sie die Variable group_replication_bootstrap_group auf ON:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;

Initialisieren Sie dann die Gruppe:

START GROUP_REPLICATION;

Danach können Sie die Variable group_replication_bootstrap_group wieder auf OFF setzen:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

Sobald das erste Mitglied die Gruppe gestartet hat, können andere Mitglieder beitreten:

START GROUP_REPLICATION;

Befolgen Sie diesen Prozess für zusätzliche Mitglieder:

START GROUP_REPLICATION;

Die Gruppe sollte jetzt online sein und alle Mitglieder verfügbar:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Dieser Prozess kann verwendet werden, um die Gruppe bei Bedarf erneut zu starten.

Schritt 8 — Automatisches Beitreten einer Gruppe beim Starten von MySQL

Mit den aktuellen Einstellungen tritt ein Mitgliedsserver beim Neustart nicht automatisch der Gruppe bei. Wenn Sie möchten, dass Mitglieder automatisch der Gruppe wieder beitreten, können Sie die Konfigurationsdatei leicht ändern.

Die Einstellung, die in diesem Schritt beschrieben wird, ist hilfreich, wenn Sie möchten, dass Mitglieder automatisch beitreten, wenn sie hochgefahren werden. Es gibt jedoch einige Dinge, auf die Sie achten sollten. Erstens betrifft diese Einstellung nur den Zeitpunkt, zu dem die MySQL-Instanz selbst gestartet wird. Wenn das Mitglied aufgrund von Timeout-Problemen aus der Gruppe entfernt wird, die MySQL-Instanz jedoch online bleibt, tritt das Mitglied nicht automatisch wieder bei.

Zweitens kann das Aktivieren dieser Einstellung beim ersten Bootstrappen einer Gruppe schädlich sein. Wenn es keine vorhandene Gruppe gibt, der beigetreten werden kann, wird der MySQL-Prozess lange dauern, um zu starten, weil er versuchen wird, andere, nicht vorhandene Mitglieder zu kontaktieren, um zu initialisieren. Erst nach einer langen Wartezeit wird er aufgeben und normal starten. Danach müssen Sie das oben beschriebene Verfahren verwenden, um die Gruppe zu bootstrappen.

Unter Berücksichtigung der oben genannten Einschränkungen, wenn Sie möchten, dass Knoten automatisch der Gruppe beitreten, wenn MySQL startet, öffnen Sie die Hauptkonfigurationsdatei von MySQL:

sudo nano /etc/mysql/my.cnf

Suchen Sie darin die Variable loose-group_replication_start_on_boot und setzen Sie sie auf ON:

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Das Mitglied sollte beim nächsten Start der MySQL-Instanz automatisch versuchen, der Gruppe beizutreten.

Zusammenfassung

Durch Abschluss dieses Tutorials haben Sie gelernt, wie Sie die MySQL-Gruppenreplikation zwischen drei Ubuntu 20.04-Servern konfigurieren können. Für Einzelprimärkonfigurationen wählen die Mitglieder automatisch einen schreibfähigen Primärserver aus, wenn dies erforderlich ist. Für Multi-Primärgruppen kann jedes Mitglied Schreib- und Aktualisierungsvorgänge durchführen.

Die Gruppenreplikation bietet eine flexible Replikationstopologie, die es Mitgliedern ermöglicht, nach Belieben beizutreten oder auszutreten, während gleichzeitig Garantien für Datenkonsistenz und Nachrichtenreihenfolge bereitgestellt werden. Die Konfiguration der MySQL-Gruppenreplikation kann etwas komplexer sein, bietet jedoch Möglichkeiten, die in herkömmlichen Replikationsmethoden nicht möglich sind.