Einführung
Die MySQL-Replikation spiegelt zuverlässig die Daten und Vorgänge von einer Datenbank in eine andere. Die herkömmliche Replikation umfasst einen Primärserver, der so konfiguriert ist, dass er Datenbankschreibvorgänge mit Sekundärservern akzeptiert, die Aktionen aus dem Protokoll des Primärservers kopieren und auf ihre eigenen Datensätze anwenden. Diese sekundären Server können für Lesevorgänge verwendet werden, können jedoch normalerweise keine Datenschreibvorgänge ausführen.
Die Gruppenreplikation ist eine Möglichkeit, einen flexibleren, fehlertoleranten Replikationsmechanismus zu implementieren. Bei diesem Prozess wird ein Pool von Servern eingerichtet, die jeweils dafür sorgen, dass die Daten korrekt kopiert werden. Wenn auf dem Primärserver Probleme auftreten, können Mitgliederwahlen einen neuen Primärserver aus der Gruppe auswählen. Auf diese Weise können die verbleibenden Knoten auch bei Problemen weiterarbeiten. Die Aushandlung der Mitgliedschaft, die Fehlererkennung und die Zustellung von Nachrichten werden durch eine Implementierung derPaxos concensus algorithm bereitgestellt.
In diesem Tutorial richten wir die MySQL-Gruppenreplikation mit drei Ubuntu 16.04-Servern ein. In der Konfiguration wird beschrieben, wie eine einzelne primäre oder mehrere primäre Replikationsgruppen betrieben werden.
Voraussetzungen
Um mitzumachen, benötigen Sie eine Gruppe von drei Ubuntu 16.04-Servern. Auf jedem dieser Server müssen Sie einen Nicht-Root-Benutzer mit den Berechtigungensudoeinrichten und eine grundlegende Firewall konfigurieren. Wir werden dieinitial server setup guide for Ubuntu 16.04 verwenden, um diese Anforderungen zu erfüllen und jeden Server in einen Bereitschaftszustand zu versetzen.
Die Version von MySQL in Ubuntus Standard-Repositorys enthält nicht das von uns benötigte Plugin für die Gruppenreplikation. Glücklicherweise unterhält das MySQL-Projekt eigene Repositorys für die neueste MySQL-Version, die diese Komponente enthält. Befolgen Sie unsere Anleitung zuinstalling the latest MySQL on Ubuntu 16.04, um auf jedem Server eine gruppenreplikationsfähige Version von MySQL zu installieren.
Generieren Sie eine UUID, um die MySQL-Gruppe zu identifizieren
Bevor Sie die MySQL-Konfigurationsdatei zum Konfigurieren der Gruppenreplikationseinstellungen öffnen, müssen Sie eine UUID generieren, mit der Sie die zu erstellende MySQL-Gruppe identifizieren können.
Verwenden Sie untermysqlmember1 den Befehluuidgen, um eine gültige UUID für die Gruppe zu generieren:
uuidgenOutput959cf631-538c-415d-8164-ca00181be227Kopieren Sie den erhaltenen Wert. Wir müssen uns gleich darauf beziehen, wenn wir einen Gruppennamen für unseren Serverpool konfigurieren.
Richten Sie die Gruppenreplikation in der MySQL-Konfigurationsdatei ein
Jetzt können wir die Konfigurationsdatei von MySQL ändern. Öffnen Sie die MySQL-Hauptkonfigurationsdatei untereach MySQL server:
sudo nano /etc/mysql/my.cnfStandardmäßig wird diese Datei nur zum Abrufen zusätzlicher Dateien aus Unterverzeichnissen verwendet. Wir müssen unsere eigene Konfigurationbeneath die!includedir Zeilen hinzufügen. Auf diese Weise können wir alle Einstellungen aus den enthaltenen Dateien leicht überschreiben.
Öffnen Sie zunächst einen Abschnitt für die MySQL-Serverkomponenten, indem Sie einen[mysqld]-Header einfügen. Darunter fügen wir die Einstellungen ein, die wir für die Gruppenreplikation benötigen. Das Präfixloose-ermöglicht es MySQL, Optionen, die nicht ohne Fehler erkannt werden, ordnungsgemäß zu verarbeiten. Viele dieser Einstellungen müssen in Kürze ausgefüllt und angepasst werden:
/etc/mysql/my.cnf
. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
[mysqld]
# General replication settings
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 = ""Wir haben die Konfiguration oben in vier Abschnitte unterteilt. Gehen wir sie jetzt durch.
Einstellungen für die Boilerplate-Gruppenreplikation
Der erste Abschnitt enthält allgemeine Einstellungen, die für die Gruppenreplikation erforderlich sind und keine Änderung erfordern:
/etc/mysql/my.cnf
. . .
# General replication settings
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
. . .Mit diesen Einstellungen werden globale Transaktions-IDs aktiviert, die für die Gruppenreplikation erforderliche binäre Protokollierung konfiguriert und SSL für die Gruppe konfiguriert. Die Konfiguration richtet auch einige andere Elemente ein, die die Wiederherstellung und das Bootstrapping unterstützen. Sie müssen in diesem Abschnitt keine Änderungen vornehmen, damit Sie nach dem Einfügen fortfahren können.
Replikationseinstellungen für freigegebene Gruppen
Im zweiten Abschnitt werden gemeinsame Einstellungen für die Gruppe festgelegt. Wir müssen dies einmal anpassen und dann auf jedem unserer Knoten dieselben Einstellungen verwenden. Dies beinhaltet die UUID für die Gruppe, eine Whitelist akzeptabler Mitglieder und Seed-Mitglieder, mit denen Sie Kontakt aufnehmen können, um erste Daten zu erhalten.
Stellen Sieloose-group_replication_group_name auf die UUID ein, die Sie zuvor mit dem Befehluuidgen generiert haben. Fügen Sie die kopierte UUID als Wert für diese Variable ein.
Setzen Sie als Nächstesloose-group_replication_ip_whitelist auf eine Liste aller IP-Adressen Ihres MySQL-Servers, die durch Kommas getrennt sind. Die Einstellungloose-group_replication_group_seedsollte fast mit der Whitelist übereinstimmen, sollte jedoch den Gruppenreplikationsport, den wir verwenden, an das Ende jedes Mitglieds anhängen. In diesem Handbuch wird der empfohlene Port 33061 für die Gruppenreplikation verwendet:
/etc/mysql/my.cnf
. . .
# Shared replication group configuration
loose-group_replication_group_name = "959cf631-538c-415d-8164-ca00181be227"
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 identisch sein. Kopieren Sie ihn daher sorgfältig.
Auswahl von Einzelprimär oder Mehrfachprimär
Als Nächstes müssen Sie entscheiden, ob Sie eine Einzelprimär- oder eine Mehrfachprimärgruppe konfigurieren möchten. In einigen Teilen der offiziellen MySQL-Dokumentation wird diese Unterscheidung auch als "Single" - oder "Multi-Master" -Replikation bezeichnet. In einer einzelnen primären Konfiguration bezeichnet MySQL einen einzelnen primären Server (fast immer das erste Gruppenmitglied), der Schreibvorgänge ausführt. Eine Multi-Primary-Gruppe ermöglicht das Schreiben an alle Gruppenmitglieder.
Wenn Sie eine Multi-Primärgruppe konfigurieren möchten, kommentieren Sie die Anweisungenloose-group_replication_single_primary_mode undloose-group_replication_enforce_update_everywhere_checksaus. Dadurch wird eine Multi-Primary-Gruppe eingerichtet. Lassen Sie für eine einzelne Primärgruppe einfach diese beiden Zeilen kommentiert:
/etc/mysql/my.cnf
. . .
# 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
. . .Diese Einstellungen müssen auf jedem Ihrer MySQL-Server gleich sein.
Sie können diese Einstellung zu einem späteren Zeitpunkt ändern, jedoch nicht, ohne Ihre MySQL-Gruppe neu zu starten. Um auf die neue Konfiguration zu wechseln, müssen Sie jede MySQL-Instanz in der Gruppe stoppen, jedes Mitglied mit den neuen Einstellungen starten und dann die Gruppenreplikation neu starten. Dies wirkt sich nicht auf Ihre Daten aus, erfordert jedoch ein kleines Ausfallfenster.
Hostspezifische Konfigurationseinstellungen
Der vierte Abschnitt enthält Einstellungen, die auf den einzelnen Servern unterschiedlich sind, darunter:
-
Die Server-ID
-
Die Adresse, an die gebunden werden soll
-
Die Adresse, die anderen Mitgliedern gemeldet werden soll
-
Die lokale Replikationsadresse und der Überwachungsport
Die Direktiveserver_idmuss auf eine eindeutige Zahl gesetzt werden. Stellen Sie dies für das erste Mitglied einfach auf „1“ und erhöhen Sie die Zahl auf jedem weiteren Host. Setzen Siebind-address undreport_host auf die IP-Adresse des aktuellen Servers, damit die MySQL-Instanz auf externe Verbindungen wartet und ihre Adresse korrekt an andere Hosts meldet. Dieloose-group_replication_local_address sollten auch auf die IP-Adresse des aktuellen Servers eingestellt werden, wobei der Gruppenreplikationsport (33061) an die IP-Adresse angehängt wird:
/etc/mysql/my.cnf
. . .
# Host specific replication configuration
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 aus.
Wenn Sie fertig sind, überprüfen Sie, ob die Einstellungen für die gemeinsame Replikation auf jedem Host identisch sind und ob die hostspezifischen Einstellungen für jeden Host angepasst sind. Speichern und schließen Sie die Datei auf jedem Host, wenn Sie fertig sind.
Starten Sie MySQL neu und aktivieren Sie den Remotezugriff
Unsere MySQL-Konfigurationsdatei enthält jetzt die Anweisungen, die zum Booten der MySQL-Gruppenreplikation erforderlich sind. Starten Sie den Dienst aufeach of your servers mit dem folgenden Befehl neu, um die neuen Einstellungen auf die MySQL-Instanz anzuwenden:
sudo systemctl restart mysqlIn der MySQL-Konfigurationsdatei haben wir den Dienst so konfiguriert, dass er auf dem Standardport 3306 auf externe Verbindungen wartet. Wir haben 33061 auch als den Port definiert, den Mitglieder für die Replikationskoordination verwenden sollten.
Wir müssen den Zugriff auf diese beiden Ports in unserer Firewall öffnen, was wir tun können, indem wir Folgendes eingeben:
sudo ufw allow 33061
sudo ufw allow 3306Wenn der Zugriff auf die MySQL-Ports geöffnet ist, können wir einen Replikationsbenutzer erstellen und das Gruppenreplikations-Plugin aktivieren.
Konfigurieren Sie den Replikationsbenutzer und aktivieren Sie das Gruppenreplikations-Plugin
Melden Sie sich untereach of your MySQL servers mit dem Administrator bei Ihrer MySQL-Instanz an, um eine interaktive Sitzung zu starten:
mysql -u root -pSie werden zur Eingabe des MySQL-Administratorkennworts aufgefordert. Anschließend werden Sie in eine MySQL-Sitzung versetzt. Als Erstes müssen wir einen Replikationsbenutzer erstellen.
Auf jedem Server ist ein Replikationsbenutzer erforderlich, um die Gruppenreplikation einzurichten. Da jeder Server einen eigenen Replikationsbenutzer hat, müssen wir die Binärprotokollierung während des Erstellungsprozesses deaktivieren. Andernfalls würde die Gruppe nach Beginn der Replikation versuchen, den Replikationsbenutzer vom Primärserver auf die anderen Server zu übertragen, wodurch ein Konflikt mit dem bereits vorhandenen Replikationsbenutzer entsteht.
Wir benötigen SSL für den Replikationsbenutzer, gewähren ihm Replikationsberechtigungen auf dem Server und leeren dann die Berechtigungen, um die Änderungen zu implementieren. Anschließend aktivieren wir die Binärprotokollierung wieder, um den normalen Betrieb wieder aufzunehmen. Stellen Sie sicher, dass Sie beim Erstellen des Replikationsbenutzers ein sicheres Kennwort verwenden:
SET SQL_LOG_BIN=0;
CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;Als Nächstes müssen wir dengroup_replication_recovery-Kanal festlegen, um unseren neuen Replikationsbenutzer und das zugehörige Kennwort zu verwenden. Jeder Server verwendet dann diese Anmeldeinformationen, um sich bei der Gruppe zu authentifizieren.
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';Mit dem vorhandenen Replikationsbenutzer können wir das Gruppenreplikations-Plugin aktivieren, um die Initialisierung der Gruppe vorzubereiten. Da wir die neueste Version von MySQL verwenden, können wir das Plugin aktivieren, indem wir Folgendes eingeben:
INSTALL PLUGIN group_replication SONAME 'group_replication.so';Stellen Sie sicher, dass das Plugin aktiv ist, indem Sie Folgendes eingeben:
SHOW PLUGINS;Output+----------------------------+----------+--------------------+----------------------+---------+
| Name | Status | Type | Library | License |
+----------------------------+----------+--------------------+----------------------+---------+
| | | | | |
| . . . | . . . | . . . | . . . | . . . |
| | | | | |
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)Die Zeilegroup_replicationbestätigt, dass das Plugin geladen wurde und derzeit aktiv ist.
Starten Sie die Gruppenreplikation
Nachdem für jeden MySQL-Server ein Replikationsbenutzer konfiguriert und das Gruppenreplikations-Plugin aktiviert wurde, können wir beginnen, unsere Gruppe aufzurufen.
Erster Bootstrap-Knoten
Führen Sie die folgenden Schritte füra single member of the group aus, um die Gruppe zu starten.
Gruppenmitglieder verlassen sich darauf, dass vorhandene Mitglieder Replikationsdaten, aktuelle Mitgliederlisten und andere Informationen senden, wenn sie der Gruppe zum ersten Mal beitreten. Aus diesem Grund müssen wir ein etwas anderes Verfahren anwenden, um das ursprüngliche Gruppenmitglied zu starten, damit es weiß, dass es diese Informationen nicht von anderen Mitgliedern in seiner Seed-Liste erwartet.
Wenn festgelegt, teilt die Variablegroup_replication_bootstrap_groupeinem Mitglied mit, dass es nicht erwarten soll, Informationen von Peers zu erhalten, sondern stattdessen eine neue Gruppe einrichten und sich selbst zum primären Mitglied wählen sollte. Da dies nur dann sinnvoll ist, wenn noch keine Gruppenmitglieder vorhanden sind, wird diese Funktion sofort nach dem Booten der Gruppe deaktiviert:
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;Die Gruppe sollte mit diesem Server als einzigem Mitglied gestartet werden. Wir können dies überprüfen, indem wir die Einträge in der Tabellereplication_group_membersin der Datenbankperformance_schemaüberprüfen:
SELECT * FROM performance_schema.replication_group_members;Sie sollten eine einzelne Zeile sehen, die den aktuellen Host darstellt:
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 |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
1 row in set (0.00 sec)Der WertONLINE fürMEMBER_STATE zeigt an, dass dieser Knoten innerhalb der Gruppe voll funktionsfähig ist.
Erstellen Sie als Nächstes eine Testdatenbank und -tabelle, um unsere Replikation zu testen:
CREATE DATABASE playground;
CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");Überprüfen Sie den Inhalt, um sicherzustellen, dass er richtig eingegeben wurde:
SELECT * FROM playground.equipment;Output+----+-------+-------+-------+
| id | type | quant | color |
+----+-------+-------+-------+
| 1 | slide | 2 | blue |
+----+-------+-------+-------+
1 row in set (0.00 sec)Wir haben jetzt überprüft, ob dieser Server Mitglied der Gruppe ist und über Schreibfunktionen verfügt. Jetzt können die anderen Server der Gruppe beitreten.
Starten Sie die verbleibenden Knoten
Starten Sie als Nächstes aufsecond server die Gruppenreplikation. Da wir bereits ein aktives Mitglied haben, müssen wir die Gruppe nicht booten und können einfach beitreten:
START GROUP_REPLICATION;Starten Sie aufthird server die Gruppenreplikation auf dieselbe Weise:
START GROUP_REPLICATION;Überprüfen Sie die Mitgliederliste erneut. Sie sollten jetzt drei Server sehen:
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)Alle Mitglieder sollten einenMEMBER_STATE-Wert vonONLINE haben. Wenn für eine neue Gruppe einer der Knoten länger als ein oder zwei Sekunden alsRECOVERING aufgeführt ist, ist dies normalerweise ein Hinweis darauf, dass ein Fehler aufgetreten ist oder etwas falsch konfiguriert wurde. Überprüfen Sie die Protokolle bei/var/log/mysql/error.log, um zusätzliche Informationen darüber zu erhalten, was schief gelaufen ist.
Überprüfen Sie, ob die Testdatenbankinformationen auf die neuen Mitglieder 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 für die neuen Mitglieder verfügbar sind, bedeutet dies, dass die Gruppenreplikation ordnungsgemäß funktioniert.
Testen der Schreibfähigkeit neuer Gruppenmitglieder
Als nächstes können wir versuchen, von unseren neuen Mitgliedern in die Datenbank zu schreiben. Ob dies erfolgreich ist oder nicht, hängt davon ab, ob Sie eine einzelne primäre oder eine mehrere primäre Gruppe konfigurieren.
Testen von Schreibvorgängen in einer einzelnen primären Umgebung
In einer einzelnen primären Gruppe sollten Sie erwarten, dass alle Schreibvorgänge vom nicht primären Server aus Konsistenzgründen abgelehnt werden. Sie können die aktuelle Primärdatenbank jederzeit mit der folgenden Abfrage ermitteln:
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 beträgtMEMBER_ID, die Sie einem Host zuordnen können, indem Sie die Liste der Gruppenmitglieder wie zuvor abfragen:
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)In diesem Beispiel sehen wir, dass der Host bei203.0.113.1 derzeit der Primärserver ist. Wenn wir versuchen, von einem anderen Mitglied in die Datenbank zu schreiben, sollten wir erwarten, dass der Vorgang fehlschlägt:
INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");OutputERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statementDies wird erwartet, da die Gruppe derzeit mit einer einzelnen schreibfähigen Primärdatenbank konfiguriert ist. Wenn der primäre Server Probleme hat und die Gruppe verlässt, wählt die Gruppe automatisch ein neues Mitglied als primäres Mitglied und akzeptiert Schreibvorgänge.
Testen von Schreibvorgängen in einer Umgebung mit mehreren Primären
Für Gruppen, die in einer Multi-Primary-Ausrichtung konfiguriert wurden, sollte jedes Mitglied Schreibzugriffe auf die Datenbank ausführen können.
Sie können überprüfen, ob Ihre Gruppe im Mehrfachprimärmodus arbeitet, indem Sie den Wert der Variablengroup_replication_primary_membererneut ü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 es keinen festgelegten primären Host gibt und jedes Mitglied Schreibvorgänge akzeptieren kann.
Testen Sie dies auf Ihrensecond server, indem Sie Folgendes eingeben:
INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");OutputQuery OK, 1 row affected (0.00 sec)Der zweite Server hat den Schreibvorgang ohne Fehler ausgeführt.
Fragen Sie aufthird server ab, 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)Hiermit wird bestätigt, dass der Schreibvorgang des zweiten Servers erfolgreich repliziert wurde.
Testen Sie nun die Schreibfunktionen auf dem dritten Server, indem Sie Folgendes eingeben:
INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");OutputQuery OK, 1 row affected (0.02 sec)Testen Sie auffirst server, ob die Schreibvorgänge der beiden neuen Mitglieder zurück 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 dass jedes Mitglied Schreibvorgänge ausführen kann.
Die Gruppe sichern
Sobald die Gruppe gebootet ist, können einzelne Mitglieder beitreten und gehen, ohne die Verfügbarkeit zu beeinträchtigen, solange genügend Mitglieder vorhanden sind, um Primärserver zu wählen. Wenn jedoch bestimmte Konfigurationsänderungen vorgenommen werden (z. B. das Wechseln zwischen einer Einzel- und einer Mehrfachprimärumgebung) oder wenn alle Mitglieder der Gruppe die Gruppe verlassen, müssen Sie die Gruppe möglicherweise neu starten. Sie tun dies genauso wie anfangs.
Legen Sie auf Ihrenfirst server die Variablegroup_replciation_bootstrap_group fest und beginnen Sie dann mit der Initialisierung der Gruppe:
SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;
START GROUP_REPLICATION;
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 weitere Mitglieder:
START GROUP_REPLICATION;Die Gruppe sollte jetzt mit allen verfügbaren Mitgliedern online sein:
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)Mit diesem Vorgang kann die Gruppe bei Bedarf erneut gestartet werden.
Automatisch einer Gruppe beitreten, wenn MySQL startet
Wenn ein Mitgliedsserver mit den aktuellen Einstellungen neu gestartet wird, tritt er beim Start nicht automatisch der Gruppe bei. Wenn Mitglieder automatisch wieder Mitglied der Gruppe werden sollen, können Sie die Konfigurationsdatei leicht ändern.
Die Einstellung, die wir skizzieren, ist hilfreich, wenn Mitglieder beim Booten automatisch beitreten sollen. Es gibt jedoch einige Dinge, die Sie beachten sollten:
Erstens wirkt sich diese Einstellung nur aus, wenn die MySQL-Instanz selbst gestartet wird. Wenn das Mitglied aufgrund von Zeitüberschreitungsproblemen aus der Gruppe entfernt wird, die MySQL-Instanz jedoch online bleibt, wird das Mitglied nicht automatisch wieder Mitglied.
Zweitens kann es schädlich sein, diese Einstellung beim ersten Bootstrapping einer Gruppe zu aktivieren. Wenn es keine Gruppe gibt, der Sie beitreten können, dauert es einige Zeit, bis der MySQL-Prozess gestartet wird, da versucht wird, andere, nicht vorhandene Mitglieder zur Initialisierung zu kontaktieren. Erst nach einer längeren Zeit wird es aufgeben und normal starten. Anschließend müssen Sie die oben beschriebene Prozedur verwenden, um die Gruppe zu booten.
Wenn Sie Knoten so konfigurieren möchten, dass sie beim Start von MySQL automatisch der Gruppe beitreten, öffnen Sie unter Berücksichtigung der oben genannten Einschränkungen die Haupt-MySQL-Konfigurationsdatei:
sudo nano /etc/mysql/my.cnfSuchen Sie im Inneren die Variableloose-group_replication_start_on_bootund setzen Sie sie auf „ON“:
/etc/mysql/my.cnf
[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 seiner MySQL-Instanz automatisch versuchen, der Gruppe beizutreten.
Fazit
In diesem Tutorial wurde die Konfiguration der MySQL-Gruppenreplikation zwischen drei Ubuntu 16.04-Servern behandelt. Bei einzelnen primären Konfigurationen wählen die Mitglieder bei Bedarf automatisch eine schreibfähige primäre. Für Multi-Primary-Gruppen kann jedes Mitglied Schreibvorgänge und Aktualisierungen durchführen.
Die Gruppenreplikation bietet eine flexible Replikationstopologie, mit der Mitglieder nach Belieben beitreten oder austreten können, während gleichzeitig die Datenkonsistenz und die Reihenfolge der Nachrichten gewährleistet werden. Die Konfiguration der MySQL-Gruppenreplikation ist möglicherweise etwas komplexer, bietet jedoch Funktionen, die bei der herkömmlichen Replikation nicht möglich sind.