So richten Sie die asynchrone Replikation vom Galera-Cluster zum eigenständigen MySQL-Server mit GTID ein

Die hybride Replikation, d. h. die Kombination von Galera und asynchroner MySQL-Replikation im selben Setup, wurde viel einfacher, seit GTID in MySQL 5.6 eingeführt wurde. Obwohl es ziemlich einfach war, von einem eigenständigen MySQL-Server auf einen Galera-Cluster zu replizieren, war es etwas schwieriger, es umgekehrt zu machen (Galera → eigenständiges MySQL). Zumindest bis zum Eintreffen von GTID.

Es gibt einige gute Gründe, einen asynchronen Slave an ein Galera-Cluster anzuschließen. Zum einen können lang andauernde Berichterstellungs-/OLAP-Abfragen auf einem Galera-Knoten einen ganzen Cluster verlangsamen, wenn die Berichtslast so intensiv ist, dass der Knoten einen erheblichen Aufwand zur Bewältigung aufwenden muss. So können Berichtsanfragen an einen eigenständigen Server gesendet werden, wodurch Galera effektiv von der Berichtslast isoliert wird. Bei einem Gürtel-und-Hosenträger-Ansatz kann ein asynchroner Slave auch als Remote-Live-Backup dienen.

In diesem Blog-Beitrag zeigen wir Ihnen, wie Sie einen Galera-Cluster mit GTID auf einen MySQL-Server replizieren und wie Sie ein Failover der Replikation durchführen, falls der Master-Knoten ausfällt.

Hybride Replikation in MySQL 5.5

In MySQL 5.5 erfordert die Wiederaufnahme einer unterbrochenen Replikation, dass Sie die letzte binäre Protokolldatei und -position bestimmen, die auf allen Galera-Knoten unterschiedlich sind, wenn die binäre Protokollierung aktiviert ist. Wir können diese Situation mit der folgenden Abbildung veranschaulichen:

Wenn der MySQL-Master ausfällt, bricht die Replikation ab und der Slave muss auf einen anderen Master umschalten. Sie müssen einen neuen Galera-Knoten auswählen und manuell eine neue binäre Protokolldatei und die Position der letzten vom Slave ausgeführten Transaktion bestimmen. Eine andere Möglichkeit besteht darin, die Daten vom neuen Master-Knoten zu sichern, sie auf dem Slave wiederherzustellen und die Replikation mit dem neuen Master-Knoten zu starten. Diese Optionen sind natürlich machbar, aber in der Produktion nicht sehr praktikabel.

Wie GTID das Problem löst

GTID (Global Transaction Identifier) ​​bietet eine bessere Transaktionszuordnung über Knoten hinweg und wird in MySQL 5.6 unterstützt. Im Galera-Cluster generieren alle Knoten unterschiedliche Binlog-Dateien. Die Binlog-Ereignisse sind dieselben und in derselben Reihenfolge, aber die Namen und Offsets der Binlog-Dateien können variieren. Mit GTID können Slaves sehen, dass eine eindeutige Transaktion von mehreren Mastern eingeht, und dies könnte leicht in die Slave-Ausführungsliste abgebildet werden, wenn die Replikation neu gestartet oder fortgesetzt werden muss.

Alle notwendigen Informationen zur Synchronisation mit dem Master werden direkt aus dem Replikationsstrom bezogen. Das bedeutet, dass Sie bei Verwendung von GTIDs für die Replikation die Optionen MASTER_LOG_FILE oder MASTER_LOG_POS nicht in die Anweisung CHANGE MASTER TO aufnehmen müssen. Stattdessen muss nur die Option MASTER_AUTO_POSITION aktiviert werden. Weitere Details zur GTID finden Sie auf der MySQL-Dokumentationsseite.

Hybridreplikation manuell einrichten

Stellen Sie sicher, dass die Galera-Knoten (Master) und Slave(s) auf MySQL 5.6 ausgeführt werden, bevor Sie mit diesem Setup fortfahren. Wir haben eine Datenbank namens sbtest in Galera, die wir auf den Slave-Knoten replizieren werden.

1. Aktivieren Sie die erforderlichen Replikationsoptionen, indem Sie die folgenden Zeilen in der Datei my.cnf jedes DB-Knotens (einschließlich des Slave-Knotens) angeben:

Für Master-Knoten (Galera):

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=1         # 1 for master1, 2 for master2, 3 for master3
binlog_format=ROW

Für Slave-Knoten:

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=101         # 101 for slave
binlog_format=ROW
replicate_do_db=sbtest
slave_net_timeout=60

2. Führen Sie einen rollierenden Cluster-Neustart des Galera-Clusters durch (über ClusterControl UI> Manage> Upgrade> Rolling Restart). Dadurch wird jeder Knoten mit den neuen Konfigurationen neu geladen und GTID aktiviert. Starten Sie auch den Slave neu.

3. Erstellen Sie einen Slave-Replikationsbenutzer und führen Sie die folgende Anweisung auf einem der Galera-Knoten aus:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY 'slavepassword';

4. Melden Sie sich beim Slave an und sichern Sie die Datenbank sbtest von einem der Galera-Knoten:

$ mysqldump -uroot -p -h192.168.0.201 --single-transaction --skip-add-locks --triggers --routines --events sbtest > sbtest.sql

5. Stellen Sie die Dump-Datei auf dem Slave-Server wieder her:

$ mysql -uroot -p < sbtest.sql

6. Starten Sie die Replikation auf dem Slave-Knoten:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.201', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Um zu überprüfen, ob die Replikation korrekt ausgeführt wird, prüfen Sie die Ausgabe von Slave-Status:

mysql> SHOW SLAVE STATUS\G
       ...
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes
       ...

Hybridreplikation mit ClusterControl einrichten

Im vorherigen Abschnitt haben wir alle notwendigen Schritte beschrieben, um die Binärprotokolle zu aktivieren, den Cluster Knoten für Knoten neu zu starten, die Daten zu kopieren und dann die Replikation einzurichten. Das Verfahren ist eine langwierige Aufgabe und Sie können leicht Fehler in einem dieser Schritte machen. In ClusterControl haben wir alle notwendigen Schritte automatisiert.

1. Benutzer von ClusterControl können auf der Knotenseite zu den Knoten gehen und die binäre Protokollierung aktivieren.

Dadurch wird ein Dialogfeld geöffnet, in dem Sie den Ablauf des Binärprotokolls festlegen, GTID aktivieren und den automatischen Neustart durchführen können.

Dadurch wird ein Job initiiert, der diese Änderungen sicher in die Konfiguration schreibt, Replikationsbenutzer mit den richtigen Berechtigungen erstellt und den Knoten sicher neu startet.

Wiederholen Sie diesen Vorgang für jeden Galera-Knoten im Cluster, bis alle Knoten angeben, dass sie Master sind.

2. Fügen Sie den asynchronen Replikations-Slave zum Cluster hinzu

Und das ist alles, was Sie tun müssen. Der gesamte im vorherigen Absatz beschriebene Prozess wurde von ClusterControl automatisiert.

Meisterwechsel

Wenn der designierte Master ausfällt, versucht der Slave erneut, sich im Wert von slave_net_timeout erneut zu verbinden (unser Setup ist 60 Sekunden - Standard ist 1 Stunde). Sie sollten den folgenden Fehler im Slave-Status sehen:

       Last_IO_Errno: 2003
       Last_IO_Error: error reconnecting to master '[email protected]:3306' - retry-time: 60  retries: 1

Da wir Galera mit aktivierter GTID verwenden, wird Master-Failover über ClusterControl bei der automatischen Cluster- und Knotenwiederherstellung unterstützt Wurde aktiviert. Unabhängig davon, ob der Master aufgrund der Netzwerkkonnektivität oder aus anderen Gründen ausfallen würde, wird ClusterControl automatisch auf den am besten geeigneten anderen Master-Knoten im Cluster umschalten.

Wenn Sie das Failover manuell durchführen möchten, ändern Sie einfach den Master-Knoten wie folgt:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

In einigen Fällen kann es vorkommen, dass nach der Änderung des Master-Knotens der Fehler „Duplicate entry .. for key“ auftritt:

       Last_Errno: 1062
       Last_Error: Could not execute Write_rows event on table sbtest.sbtest; Duplicate entry '1089775' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysqld-bin.000009, end_log_pos 85789000

In älteren Versionen von MySQL können Sie einfach SET GLOBAL SQL_SLAVE_SKIP_COUNTER =n verwenden um Anweisungen zu überspringen, aber es funktioniert nicht mit GTID. Miguel von Percona hat einen großartigen Blogbeitrag darüber geschrieben, wie man dies durch Einfügen leerer Transaktionen beheben kann.

Ein anderer Ansatz für kleinere Datenbanken könnte auch darin bestehen, einfach einen neuen Dump von einem der verfügbaren Galera-Knoten zu erhalten, ihn wiederherzustellen und die RESET MASTER-Anweisung zu verwenden:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> DROP SCHEMA sbtest; CREATE SCHEMA sbtest; USE sbtest;
mysql> SOURCE /root/sbtest_from_galera2.sql; -- repeat step #4 above to get this dump
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Sie können auch pt-table-checksum verwenden, um die Replikationsintegrität zu überprüfen, weitere Informationen in diesem Blogbeitrag.

Hinweis:Da bei der MySQL-Replikation der Slave-Applierer standardmäßig immer noch Single-Threaded ist, erwarten Sie nicht, dass die asynchrone Replikationsleistung dieselbe ist wie die parallele Replikation von Galera. Für MySQL 5.6 und 5.7 gibt es Optionen, um die asynchrone Replikation parallel auf den Slave-Knoten auszuführen, aber im Prinzip hängt diese Replikation immer noch von der richtigen Reihenfolge der Transaktionen innerhalb desselben Schemas ab. Wenn die Replikationslast intensiv und kontinuierlich ist, wird die Slave-Verzögerung einfach weiter wachsen. Wir haben Fälle gesehen, in denen der Sklave den Meister nie einholen konnte.