Binäre Protokolle (Binlogs) enthalten Aufzeichnungen aller Änderungen an den Datenbanken. Sie sind für die Replikation erforderlich und können auch zur Wiederherstellung von Daten nach einer Sicherung verwendet werden. Ein Binlog-Server ist im Grunde ein binäres Log-Repository. Sie können es sich wie einen Server vorstellen, dessen Zweck es ist, Binärprotokolle von einem Master abzurufen, während Slave-Server sich damit verbinden können, als würden sie sich mit einem Master-Server verbinden.
Einige Vorteile eines Binlog-Servers gegenüber einem zwischengeschalteten Master zur Verteilung der Replikationslast sind:
- Sie können auf einen neuen Masterserver wechseln, ohne dass die Slaves merken, dass sich der eigentliche Masterserver geändert hat. Dies ermöglicht eine höher verfügbare Replikationskonfiguration, bei der die Replikation eine hohe Priorität hat.
- Reduzieren Sie die Belastung des Masters, indem Sie statt aller Slaves nur den Binlog-Server von Maxscale bedienen.
- Die Daten im Binärlog des Zwischenmasters sind keine direkte Kopie der Daten, die vom Binärlog des echten Masters empfangen wurden. Wenn also Gruppen-Commit verwendet wird, kann dies zu einer Verringerung der Parallelität der Commits und einer anschließenden Verringerung der Leistung der Slave-Server führen.
- Zwischensklave muss jede SQL-Anweisung erneut ausführen, was möglicherweise Latenz hinzufügt und in der Replikationskette verzögert.
In diesem Blog-Beitrag werden wir untersuchen, wie ein Zwischenmaster (ein Slave-Host-Relay zu anderen Slaves in einer Replikationskette) durch einen Binlog-Server ersetzt werden kann, der auf MaxScale läuft, um eine bessere Skalierbarkeit und Leistung zu erzielen .
Architektur
Wir haben im Grunde ein 4-Knoten-MariaDB v10.4-Replikations-Setup mit einem MaxScale v2.3, das auf der Replikation sitzt, um eingehende Abfragen zu verteilen. Nur ein Slave ist mit einem Master (Zwischenmaster) verbunden und die anderen Slaves replizieren vom Zwischenmaster, um Lese-Workloads zu bedienen, wie im folgenden Diagramm dargestellt.
Wir werden die obige Topologie wie folgt umwandeln:
Grundsätzlich werden wir die Zwischenmasterrolle entfernen und durch ersetzen ein Binlog-Server, der auf MaxScale läuft. Der Intermediate Master wird wie andere Slave-Hosts in einen Standard-Slave umgewandelt. Der Binlog-Dienst überwacht Port 5306 auf dem MaxScale-Host. Dies ist der Port, mit dem sich später alle Slaves für die Replikation verbinden werden.
MaxScale als Binlog-Server konfigurieren
In diesem Beispiel haben wir bereits eine MaxScale auf unserem Replikationscluster, die als Load Balancer für unsere Anwendungen fungiert. Wenn Sie kein MaxScale haben, können Sie ClusterControl zum Bereitstellen verwenden, gehen Sie einfach zu Cluster Actions -> Load Balancer hinzufügen -> MaxScale und füllen Sie die erforderlichen Informationen wie folgt aus:
Bevor wir beginnen, exportieren wir die aktuelle MaxScale-Konfiguration in eine Textdatei für Sicherung. MaxScale hat für diesen Zweck ein Flag namens --export-config, aber es muss als maxscale-Benutzer ausgeführt werden. Der Befehl zum Exportieren lautet also:
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscaleErstellen Sie auf dem MariaDB-Master einen Replikations-Slave-Benutzer namens „maxscale_slave“, der von MaxScale verwendet werden soll, und weisen Sie ihm die folgenden Berechtigungen zu:
$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';ClusterControl-Benutzer gehen zu Verwalten -> Schemata und Benutzer, um die erforderlichen Berechtigungen zu erstellen.
Bevor wir mit der Konfiguration fortfahren, ist es wichtig, den aktuellen Zustand und die Topologie unserer Backend-Server zu überprüfen:
$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0 │ Master, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0 │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘Wie wir sehen können, ist der aktuelle Master DB_757 (192.168.0.90). Beachten Sie diese Informationen, da wir den Binlog-Server so einrichten werden, dass er von diesem Master repliziert.
Öffnen Sie die MaxScale-Konfigurationsdatei unter /etc/maxscale.cnf und fügen Sie die folgenden Zeilen hinzu:
[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master
[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0Eine kleine Erklärung - Wir erstellen zwei Komponenten - Service und Listener. Beim Service definieren wir die Eigenschaft des Binlog-Servers und wie er laufen soll. Details zu jeder Option finden Sie hier. In diesem Beispiel laufen unsere Replikationsserver mit halbsynchroner Replikation, daher müssen wir semisync=true verwenden, damit eine Verbindung zum Master über die halbsynchrone Replikationsmethode hergestellt wird. Der Listener ist der Ort, an dem wir den Listening-Port mit dem binlogrouter-Dienst innerhalb von MaxScale abbilden.
Starten Sie MaxScale neu, um die Änderungen zu laden:
$ systemctl restart maxscaleVergewissern Sie sich, dass der Binlog-Dienst über maxctrl gestartet wurde (sehen Sie sich die Statusspalte an):
$ maxctrl show service replication-serviceVergewissern Sie sich, dass MaxScale jetzt einen neuen Port für den Binlog-Dienst überwacht:
$ netstat -tulpn | grep maxscale
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:5306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 127.0.0.1:8989 0.0.0.0:* LISTEN 4850/maxscaleWir können jetzt eine Replikationsverbindung zwischen MaxScale und dem Master herstellen.
Aktivierung des Binlog-Servers
Melden Sie sich beim MariaDB-Masterserver an und rufen Sie die aktuelle Binlog-Datei und Position ab:
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+Verwenden Sie die Funktion BINLOG_GTID_POS, um den GTID-Wert zu erhalten:
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+Zurück zum MaxScale-Server, installieren Sie das MariaDB-Client-Paket:
$ yum install -y mysql-client
Verbinden Sie sich mit dem Binlog-Server-Listener auf Port 5306 als maxscale_slave-Benutzer und stellen Sie eine Replikationsverbindung zum designierten Master her. Verwenden Sie den vom Master abgerufenen GTID-Wert:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Binlog Dump
Master_Host: 192.168.0.90
Master_User: maxscale_slave
Master_Port: 3306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 38001
Master_Info_File: /var/lib/maxscale/binlogs/master.ini
Slave_SQL_Running_State: Slave running
Gtid_IO_Pos: 0-38001-31Hinweis:Die obige Ausgabe wurde abgeschnitten, um nur wichtige Zeilen anzuzeigen.
Zeigt Slaves auf den Binlog-Server
Ändern Sie nun auf mariadb2 und mariadb3 (den End-Slaves) den Master, der auf den MaxScale-Binlog-Server zeigt. Da wir mit aktivierter Semi-Sync-Replikation laufen, müssen wir sie zuerst deaktivieren:
(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update itHinweis:Die obige Ausgabe wurde abgeschnitten, um nur wichtige Zeilen anzuzeigen.
Innerhalb von my.cnf müssen wir die folgenden Zeilen kommentieren, um Semi-Sync in Zukunft zu deaktivieren:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONZu diesem Zeitpunkt repliziert der Zwischenmaster (mariadb1) immer noch vom Master (mariadb0), während andere Slaves vom Binlog-Server repliziert haben. Unsere aktuelle Topologie kann wie im folgenden Diagramm dargestellt werden:
Der letzte Teil besteht darin, die Master-Zeigerung des Zwischenmasters (mariadb1 ), nachdem alle Sklaven, die sich früher daran angehängt hatten, nicht mehr da sind. Die Schritte sind bei den anderen Slaves grundsätzlich gleich:
(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32Hinweis:Die obige Ausgabe wurde abgeschnitten, um nur wichtige Zeilen anzuzeigen.
Vergessen Sie nicht, auch die halbsynchrone Replikation in my.cnf zu deaktivieren:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONWir können überprüfen, ob der binlog-Routerdienst jetzt über die maxctrl-CLI mehr Verbindungen hat:
$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Servers │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service │ readwritesplit │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service │ readconnroute │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter │ 4 │ 51 │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘Außerdem können innerhalb des MaxScale-Binlog-Servers gängige Replikationsverwaltungsbefehle verwendet werden, zum Beispiel können wir die verbundenen Slave-Hosts mit diesem Befehl überprüfen:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003 | 192.168.0.92 | 3306 | 9999 | |
| 38002 | 192.168.0.91 | 3306 | 9999 | |
| 38004 | 192.168.0.93 | 3306 | 9999 | |
+-----------+--------------+------+-----------+------------+An diesem Punkt sieht unsere Topologie so aus, wie wir es erwartet haben:
Unsere Migration vom Intermediate-Master-Setup zum Binlog-Server-Setup ist nun abgeschlossen.
