ProxySQL ist einer der besten Proxys für MySQL. Es führte viele Optionen für Datenbankadministratoren ein. Es ermöglichte, den Datenbankverkehr zu formen, indem Abfragen im laufenden Betrieb verzögert, zwischengespeichert oder umgeschrieben wurden. Es kann auch verwendet werden, um eine Umgebung zu schaffen, in der Failover Anwendungen nicht beeinträchtigen und für sie transparent sind. Die wichtigsten ProxySQL-Features haben wir bereits in früheren Blogbeiträgen behandelt:
- Verwendung von ClusterControl und ProxySQL zum Caching von Abfragen
- Wie man eine SQL-Firewall mit ClusterControl und ProxySQL baut
- So stellen Sie einen ProxySQL-Cluster bereit
- Einfache Bereitstellung einer MySQL-Replikationsumgebung mit ProxySQL für Hochverfügbarkeit
Wir haben sogar ein Tutorial zu ProxySQL, das zeigt, wie es in MySQL- und MariaDB-Setups verwendet werden kann.
Vor kurzem wurde ProxySQL 2.0.3 veröffentlicht, ein Patch-Release für die 2.0-Serie. Fehler werden behoben und die 2.0-Linie scheint die Traktion zu bekommen, die sie verdient. In diesem Blogbeitrag möchten wir die wichtigsten Änderungen diskutieren, die in ProxySQL 2.0 eingeführt wurden.
Kausale Lesevorgänge mit GTID
Alle, die mit Replikationsverzögerungen zu kämpfen hatten und mit Read-after-Write-Szenarien zu kämpfen hatten, die von Replikationsverzögerungen betroffen sind, werden mit dieser Funktion definitiv sehr zufrieden sein. Bisher war in MySQL-Replikationsumgebungen die einzige Möglichkeit, kausale Lesevorgänge sicherzustellen, das Lesen vom Master (und es spielt keine Rolle, ob Sie asynchrone oder semisynchrone Replikation verwenden). Eine andere Option war, sich für Galera zu entscheiden, das seit jeher eine Option zum Erzwingen kausaler Lesevorgänge hatte (zuerst war es wsrep-causal-reads und jetzt ist es wsrep-sync-wait). Vor kurzem (in 8.0.14) erhielt die MySQL-Gruppenreplikation eine ähnliche Funktion. Eine regelmäßige Replikation allein kann dieses Problem jedoch nicht lösen. Glücklicherweise ist ProxySQL hier und bringt uns eine Option, um auf Basis von Regeln pro Abfrage zu definieren, welche Hostgruppe liest, welche Übereinstimmung mit dieser Abfrageregel konsistent sein sollte. Die Implementierung wird mit dem ProxySQL-Binlog-Reader geliefert und kann mit dem ROW-Binlog-Format für MySQL 5.7 und neuer arbeiten. Aufgrund fehlender erforderlicher Funktionen in MariaDB wird nur Oracle MySQL unterstützt. Diese Funktion und ihre technischen Details wurden im offiziellen ProxySQL-Blog erklärt.
SSL für Frontend-Verbindungen
ProxySQL hatte immer Unterstützung für Backend-SSL-Verbindungen, aber es fehlte die SSL-Verschlüsselung für die Verbindungen, die von Clients kamen. Dies war keine große Sache, da das empfohlene Bereitstellungsmuster darin bestand, ProxySQL auf Anwendungsknoten zu bündeln und einen sicheren Unix-Socket zu verwenden, um eine Verbindung von der App zum Proxy herzustellen. Dies ist immer noch eine Empfehlung, insbesondere wenn Sie ProxySQL zum Caching von Abfragen verwenden (Unix-Sockets sind schneller als TCP-Verbindungen, sogar lokale, und mit Cache ist es gut, unnötige Latenzzeiten zu vermeiden). Was gut ist, ist, dass es mit ProxySQL 2.0 jetzt eine Auswahl gibt, da es SSL-Unterstützung für eingehende Verbindungen eingeführt hat. Sie können es einfach aktivieren, indem Sie mysql-have_ssl auf „true“ setzen. Die Aktivierung von SSL hat keine inakzeptablen Auswirkungen auf die Leistung. Im Gegensatz dazu ist der Leistungsabfall gemäß den Ergebnissen des offiziellen ProxySQL-Blogs sehr gering.
Native Unterstützung für Galera-Cluster
Galera Cluster wurde fast von Anfang an von ProxySQL unterstützt, aber bisher geschah dies über das externe Skript, das (typischerweise) vom internen Scheduler von ProxySQL aufgerufen wurde. Es war Aufgabe des Skripts sicherzustellen, dass die ProxySQL-Konfiguration korrekt war, der Writer (oder die Writer) korrekt erkannt und in der Writer-Hostgruppe konfiguriert wurden. Das Skript war in der Lage, die verschiedenen Zustände zu erkennen, die der Galera-Knoten haben kann (primär, nicht-primär, synchronisiert, Donor/Desynchronisierung, beitretend, beigetreten) und den Knoten entsprechend entweder als verfügbar oder nicht zu markieren. Das Hauptproblem ist, dass das ursprüngliche Skript nie als etwas anderes als der in Bash geschriebene Proof of Concept gedacht war. Doch als es zusammen mit ProxySQL verteilt wurde, wurde es verbessert und von externen Mitwirkenden modifiziert. Andere (wie Percona) versuchten, ihre eigenen Skripte zu erstellen, die mit ihrer Software gebündelt waren. Einige Korrekturen wurden in das Skript aus dem ProxySQL-Repository eingeführt, andere wurden in die Percona-Version des Skripts eingeführt. Dies führte zu Verwirrung, und obwohl alle gängigen Skripte 95 % der Anwendungsfälle abdeckten, deckte keines der gängigen Skripte wirklich alle unterschiedlichen Situationen und Variablen ab, die Galera-Cluster möglicherweise verwenden. Glücklicherweise bietet ProxySQL 2.0 native Unterstützung für Galera Cluster. Dadurch unterstützt ProxySQL intern MySQL-Replikation, MySQL-Gruppenreplikation und jetzt Galera Cluster. Die Art und Weise, wie es gemacht wird, ist sehr ähnlich. Wir möchten die Konfiguration dieser Funktion behandeln, da sie auf den ersten Blick möglicherweise nicht klar ist.
Wie bei der MySQL-Replikation und der MySQL-Gruppenreplikation wurde eine Tabelle in ProxySQL erstellt:
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)Es gibt zahlreiche Einstellungen, die konfiguriert werden müssen, und wir werden sie nacheinander durchgehen. Zunächst einmal gibt es vier Hostgruppen:
- Writer_hostgroup – enthält alle Autoren (mit read_only=0) bis zur Einstellung „max_writers“. Standardmäßig ist es nur ein Schreiber
- Backup_writer_hostgroup – es enthält verbleibende Writer (read_only=0), die übrig bleiben, nachdem „max_writers“ zu writer_hostgroup hinzugefügt wurde
- Reader_hostgroup – enthält Leser (read_only=1), kann auch Sicherungsschreiber enthalten, gemäß der Einstellung „writer_is_also_reader“
- Offline_hostgroup – enthält Knoten, die als nicht verwendbar erachtet wurden (entweder offline oder in einem Zustand, der es ihnen unmöglich macht, Datenverkehr zu bewältigen)
Dann haben wir verbleibende Einstellungen:
- Aktiv - ob der Eintrag in mysql_galera_hostgroups aktiv ist oder nicht
- Max_writers - wie viele Knoten maximal in die write_hostgroup aufgenommen werden können
- Writer_is_also_reader - wenn auf 0 gesetzt, werden Writer (read_only=0) nicht in reader_hostgroup gestellt. Wenn auf 1 gesetzt, werden Writer (read_only=0) in reader_hostgroup gestellt. Wenn auf 2 gesetzt, werden Knoten von backup_writer_hostgroup in reader_hostgroup gestellt. Dieser ist etwas komplex, daher werden wir später in diesem Blogbeitrag ein Beispiel vorstellen
- Max_transactions_behind – basierend auf wsrep_local_recv_queue, der maximal akzeptablen Warteschlange. Wenn die Warteschlange auf dem Knoten max_transactions_behind überschreitet, wird der angegebene Knoten als SHUNNED markiert und steht nicht für den Datenverkehr zur Verfügung
Die größte Überraschung könnte die Handhabung der Reader sein, die sich von der Funktionsweise des in ProxySQL enthaltenen Skripts unterscheidet. Zuallererst müssen Sie beachten, dass ProxySQL read_only=1 verwendet, um zu entscheiden, ob der Knoten ein Leser ist oder nicht. Dies ist bei Replikations-Setups üblich, bei Galera nicht so üblich. Daher werden Sie höchstwahrscheinlich die Einstellung „writer_is_also_reader“ verwenden wollen, um zu konfigurieren, wie Leser zur reader_hostgroup hinzugefügt werden sollen. Betrachten wir drei Galera-Knoten, alle haben read_only=0. Wir haben auch max_writers=1, da wir alle Schreibvorgänge auf einen Knoten richten möchten. Wir haben mysql_galera_hostgroups wie folgt konfiguriert:
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)Gehen wir alle Optionen durch:
writer_is_also_reader=0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)Dieses Ergebnis unterscheidet sich von dem, was Sie in den Skripten sehen würden – dort würden Sie verbleibende Knoten als Leser markieren. Da wir hier nicht wollen, dass Writer Reader sind und es keinen Knoten mit read_only=1 gibt, werden keine Reader konfiguriert. Ein Writer (gemäß max_writers), verbleibende Knoten in backup_writer_hostgroup.
writer_is_also_reader=1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)Hier wollen wir, dass unsere Autoren als Leser fungieren, daher werden sie alle (aktiv und Backup) in die reader_hostgroup gestellt.
writer_is_also_reader=2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)Dies ist eine Einstellung für diejenigen, die nicht möchten, dass ihr aktiver Schreiber Lesevorgänge verarbeitet. In diesem Fall werden nur Knoten aus backup_writer_hostgroup für Lesevorgänge verwendet. Bitte denken Sie auch daran, dass sich die Anzahl der Leser ändert, wenn Sie max_writers auf einen anderen Wert setzen. Wenn wir es auf 3 setzen würden, gäbe es keine Backup-Writer (alle Knoten würden in der Writer-Hostgruppe landen), also gäbe es wiederum keine Knoten in der Reader-Hostgruppe.
Natürlich möchten Sie die Abfrageregeln entsprechend der Konfiguration der Hostgruppe konfigurieren. Wir werden diesen Prozess hier nicht durchgehen, Sie können im ProxySQL-Blog nachlesen, wie er durchgeführt werden kann. Wenn Sie testen möchten, wie es in einer Docker-Umgebung funktioniert, haben wir einen Blog, der behandelt, wie Galera-Cluster und ProxySQL 2.0 auf Docker ausgeführt werden.
Weitere Änderungen
Was wir oben beschrieben haben, sind die bemerkenswertesten Verbesserungen in ProxySQL 2.0. Laut Änderungsprotokoll gibt es noch viele andere. Erwähnenswert sind Verbesserungen rund um den Abfrage-Cache (z. B. Hinzufügen von PROXYSQL FLUSH QUERY CACHE) und Änderungen, die es ProxySQL ermöglichen, sich auf super_read_only zu verlassen, um Master und Slaves in der Replikationskonfiguration zu bestimmen.
Wir hoffen, dass dieser kurze Überblick über die Änderungen in ProxySQL 2.0 Ihnen hilft, festzustellen, welche Version von ProxySQL Sie verwenden sollten. Bitte denken Sie daran, dass der 1.4-Zweig, auch wenn er keine neuen Funktionen erhält, immer noch gepflegt wird.
