ProxySQL ist ein intelligenter und leistungsstarker SQL-Proxy, der MySQL, MariaDB und ClickHouse unterstützt. Kürzlich wurde ProxySQL 2.0 allgemein verfügbar und bietet neue aufregende Funktionen wie GTID-konsistente Lesevorgänge, Frontend-SSL, Galera und native Unterstützung für MySQL-Gruppenreplikation.
Es ist relativ einfach, ProxySQL als Docker-Container auszuführen. Wir haben bereits darüber geschrieben, wie ProxySQL auf Kubernetes als Hilfscontainer oder als Kubernetes-Dienst ausgeführt wird, der auf ProxySQL 1.x basiert. In diesem Blogbeitrag verwenden wir die neue Version ProxySQL 2.x, die einen anderen Ansatz für die Galera-Cluster-Konfiguration verwendet.
ProxySQL 2.x Docker-Image
Wir haben einen neuen ProxySQL 2.0-Docker-Image-Container veröffentlicht, der in Docker Hub verfügbar ist. Die README enthält eine Reihe von Konfigurationsbeispielen, insbesondere für Galera und MySQL Replication, vor und nach v2.x. Die Konfigurationszeilen können in einer Textdatei definiert und dem Pfad des Containers unter /etc/proxysql.cnf zugeordnet werden, um in den ProxySQL-Dienst geladen zu werden.
Das Image-Tag „neueste“ zeigt immer noch auf 1.x, bis ProxySQL 2.0 offiziell GA wird (wir haben noch keinen offiziellen Release-Blog/Artikel vom ProxySQL-Team gesehen). Das heißt, wann immer Sie das ProxySQL-Image mit dem neuesten Tag von Multiplenines installieren, erhalten Sie immer noch Version 1.x damit. Beachten Sie, dass die neuen Beispielkonfigurationen auch ProxySQL-Webstatistiken aktivieren (eingeführt in 1.4.4, aber noch in der Betaphase) – ein einfaches Dashboard, das die Gesamtkonfiguration und den Status von ProxySQL selbst zusammenfasst.
ProxySQL 2.x-Unterstützung für Galera-Cluster
Lassen Sie uns ausführlicher über die native Unterstützung von Galera Cluster sprechen. Die neue Tabelle mysql_galera_hostgroups besteht aus den folgenden Feldern:
- writer_hostgroup : ID der Hostgruppe, die alle Mitglieder enthält, die Autoren sind (read_only=0).
- backup_writer_hostgroup : Wenn der Cluster im Multi-Writer-Modus läuft (d. h. es gibt mehrere Knoten mit read_only=0) und max_writers auf eine kleinere Zahl als die Gesamtzahl der Knoten eingestellt ist, werden die zusätzlichen Knoten in diese Backup-Writer-Hostgruppe verschoben.
- reader_hostgroup : ID der Hostgruppe, die alle Mitglieder enthält, die Leser sind (d. h. Knoten mit read_only=1)
- offline_hostgroup : Wenn die ProxySQL-Überwachung feststellt, dass ein Host OFFLINE ist, wird der Host in die offline_hostgroup verschoben.
- aktiv : ein boolescher Wert (0 oder 1), um eine Hostgruppe zu aktivieren
- max_writers : Steuert die maximale Anzahl zulässiger Knoten in der Writer-Hostgruppe. Wie bereits erwähnt, werden zusätzliche Knoten in die backup_writer_hostgroup verschoben.
- Schreiber_ist_auch_Leser : Wenn 1, wird ein Knoten in der write_hostgroup auch in der reader_hostgroup platziert, sodass er für Lesevorgänge verwendet wird. Wenn der Wert auf 2 gesetzt ist, werden die Knoten von backup_writer_hostgroup in reader_hostgroup platziert, anstelle der Knoten in der write_hostgroup.
- max_transactions_behind : bestimmt die maximale Anzahl von Writesets, die ein Knoten im Cluster in die Warteschlange gestellt haben kann, bevor der Knoten SHUNNED wird, um veraltete Lesevorgänge zu verhindern (dies wird durch Abfragen der Galera-Variablen wsrep_local_recv_queue bestimmt).
- kommentieren : Textfeld, das für beliebige, vom Benutzer definierte Zwecke verwendet werden kann
Hier ist eine Beispielkonfiguration für mysql_galera_hostgroups im Tabellenformat:
Admin> select * from mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 20
reader_hostgroup: 30
offline_hostgroup: 9999
active: 1
max_writers: 1
writer_is_also_reader: 2
max_transactions_behind: 20
comment: ProxySQL führt Galera-Zustandsprüfungen durch, indem es den folgenden MySQL-Status bzw. die folgende MySQL-Variable überwacht:
- read_only - Wenn ON, gruppiert ProxySQL den definierten Host in reader_hostgroup, es sei denn, author_is_also_reader ist 1.
- wsrep_desync - Wenn ON, markiert ProxySQL den Knoten als nicht verfügbar und verschiebt ihn nach offline_hostgroup.
- wsrep_reject_queries - Wenn diese Variable eingeschaltet ist, markiert ProxySQL den Knoten als nicht verfügbar und verschiebt ihn in die offline_hostgroup (nützlich in bestimmten Wartungssituationen).
- wsrep_sst_donor_rejects_queries - Wenn diese Variable aktiviert ist, markiert ProxySQL den Knoten als nicht verfügbar, während der Galera-Knoten als SST-Spender dient, und verschiebt ihn in die offline_hostgroup.
- wsrep_local_state - Wenn dieser Status einen anderen Wert als 4 zurückgibt (4 bedeutet synchronisiert), markiert ProxySQL den Knoten als nicht verfügbar und verschiebt ihn in offline_hostgroup.
- wsrep_local_recv_queue - Wenn dieser Status höher als max_transactions_behind ist, wird der Knoten gemieden.
- wsrep_cluster_status - Wenn dieser Status einen anderen als Primär zurückgibt, markiert ProxySQL den Knoten als nicht verfügbar und verschiebt ihn in offline_hostgroup.
Durch die Kombination dieser neuen Parameter in mysql_galera_hostgroups zusammen mit mysql_query_rules hat ProxySQL 2.x die Flexibilität, sich in viel mehr Galera-Anwendungsfälle einzufügen. Beispielsweise kann eine Single-Writer-, Multi-Writer- und Multi-Reader-Hostgruppe als Ziel-Hostgruppe einer Abfrageregel definiert werden, mit der Möglichkeit, die Anzahl der Writer zu begrenzen und das Verhalten veralteter Lesevorgänge genauer zu steuern.
Vergleichen Sie dies mit ProxySQL 1.x, wo der Benutzer explizit einen Planer definieren musste, um ein externes Skript aufzurufen, um die Back-End-Zustandsprüfungen durchzuführen und den Status des Datenbankservers zu aktualisieren. Dies erfordert eine gewisse Anpassung des Skripts (der Benutzer muss den ProxySQL-Admin-Benutzer/Passwort/Port aktualisieren) und es hing von einem zusätzlichen Tool (MySQL-Client) ab, um sich mit der ProxySQL-Admin-Oberfläche zu verbinden.
Hier ist eine Beispielkonfiguration des Galera Health Check Script Schedulers im Tabellenformat für ProxySQL 1.x:
Admin> select * from scheduler\G
*************************** 1. row ***************************
id: 1
active: 1
interval_ms: 2000
filename: /usr/share/proxysql/tools/proxysql_galera_checker.sh
arg1: 10
arg2: 20
arg3: 1
arg4: 1
arg5: /var/lib/proxysql/proxysql_galera_checker.log
comment:Da außerdem der ProxySQL-Scheduler-Thread jedes Skript unabhängig ausführt, sind viele Versionen von Zustandsprüfungsskripten verfügbar. Alle von ClusterControl bereitgestellten ProxySQL-Instanzen verwenden das Standardskript, das vom ProxySQL-Installationspaket bereitgestellt wird.
In ProxySQL 2.x können die Variablen „max_writers“ und „writer_is_also_reader“ bestimmen, wie ProxySQL die Back-End-MySQL-Server dynamisch gruppiert und die Verbindungsverteilung und das Abfragerouting direkt beeinflussen. Betrachten Sie beispielsweise die folgenden MySQL-Backend-Server:
Admin> select hostgroup_id, hostname, status, weight from mysql_servers;
+--------------+--------------+--------+--------+
| hostgroup_id | hostname | status | weight |
+--------------+--------------+--------+--------+
| 10 | DB1 | ONLINE | 1 |
| 10 | DB2 | ONLINE | 1 |
| 10 | DB3 | ONLINE | 1 |
+--------------+--------------+--------+--------+Zusammen mit der folgenden Galera-Hostgruppendefinition:
Admin> select * from mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 20
reader_hostgroup: 30
offline_hostgroup: 9999
active: 1
max_writers: 1
writer_is_also_reader: 2
max_transactions_behind: 20
comment: Da alle Hosts betriebsbereit sind, wird ProxySQL die Hosts höchstwahrscheinlich wie folgt gruppieren:
Sehen wir sie uns nacheinander an:
| Konfiguration | Beschreibung |
|---|---|
| writer_is_also_reader=0 |
|
| writer_is_also_reader=1 |
|
| writer_is_also_reader=2 |
|
Mit dieser Konfiguration kann man verschiedene Auswahlmöglichkeiten für das Ziel der Hostgruppe haben, um bestimmten Arbeitslasten gerecht zu werden. "Hotspot"-Schreibvorgänge können so konfiguriert werden, dass sie nur an einen Server gehen, um Multi-Master-Konflikte zu reduzieren, konfliktfreie Schreibvorgänge können gleichmäßig auf die anderen Master verteilt werden, die meisten Lesevorgänge können gleichmäßig auf alle MySQL-Server oder Nicht-Schreiber verteilt werden, kritische Lesevorgänge können an die aktuellsten Server weitergeleitet werden und analytische Lesevorgänge können an eine Slave-Replik weitergeleitet werden.
ProxySQL-Bereitstellung für Galera-Cluster
Angenommen, wir haben in diesem Beispiel bereits einen Galera-Cluster mit drei Knoten, der von ClusterControl bereitgestellt wird, wie im folgenden Diagramm gezeigt:
Unsere Wordpress-Anwendungen laufen auf Docker, während die Wordpress-Datenbank auf unserem Galera-Cluster gehostet wird, das auf Bare-Metal-Servern läuft. Wir haben uns entschieden, neben unseren Wordpress-Containern einen ProxySQL-Container auszuführen, um eine bessere Kontrolle über das Routing von Wordpress-Datenbankabfragen zu haben und unsere Datenbank-Cluster-Infrastruktur voll auszunutzen. Da das Lese-Schreib-Verhältnis bei etwa 80 % bis 20 % liegt, möchten wir ProxySQL folgendermaßen konfigurieren:
- Alle Schreibvorgänge an einen Galera-Knoten weiterleiten (weniger Konflikte, Fokus auf Schreiben)
- Verteilen Sie alle Lesevorgänge auf die anderen beiden Galera-Knoten (bessere Verteilung für den Großteil der Arbeitslast)
Erstellen Sie zunächst eine ProxySQL-Konfigurationsdatei im Docker-Host, damit wir sie unserem Container zuordnen können:
$ mkdir /root/proxysql-docker
$ vim /root/proxysql-docker/proxysql.cnfKopieren Sie dann die folgenden Zeilen (wir erklären die Konfigurationszeilen weiter unten):
datadir="/var/lib/proxysql"
admin_variables=
{
admin_credentials="admin:admin"
mysql_ifaces="0.0.0.0:6032"
refresh_interval=2000
web_enabled=true
web_port=6080
stats_credentials="stats:admin"
}
mysql_variables=
{
threads=4
max_connections=2048
default_query_delay=0
default_query_timeout=36000000
have_compress=true
poll_timeout=2000
interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
default_schema="information_schema"
stacksize=1048576
server_version="5.1.30"
connect_timeout_server=10000
monitor_history=60000
monitor_connect_interval=200000
monitor_ping_interval=200000
ping_interval_server_msec=10000
ping_timeout_server=200
commands_stats=true
sessions_sort=true
monitor_username="proxysql"
monitor_password="proxysqlpassword"
monitor_galera_healthcheck_interval=2000
monitor_galera_healthcheck_timeout=800
}
mysql_galera_hostgroups =
(
{
writer_hostgroup=10
backup_writer_hostgroup=20
reader_hostgroup=30
offline_hostgroup=9999
max_writers=1
writer_is_also_reader=1
max_transactions_behind=30
active=1
}
)
mysql_servers =
(
{ address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }
)
mysql_query_rules =
(
{
rule_id=100
active=1
match_pattern="^SELECT .* FOR UPDATE"
destination_hostgroup=10
apply=1
},
{
rule_id=200
active=1
match_pattern="^SELECT .*"
destination_hostgroup=30
apply=1
},
{
rule_id=300
active=1
match_pattern=".*"
destination_hostgroup=10
apply=1
}
)
mysql_users =
(
{ username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 },
{ username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }
)Lassen Sie uns nun einige der Konfigurationsabschnitte besuchen. Zuerst definieren wir die Konfiguration der Galera-Hostgruppen wie folgt:
mysql_galera_hostgroups =
(
{
writer_hostgroup=10
backup_writer_hostgroup=20
reader_hostgroup=30
offline_hostgroup=9999
max_writers=1
writer_is_also_reader=1
max_transactions_behind=30
active=1
}
)Hostgruppe 10 ist die write_hostgroup, Hostgruppe 20 für backup_writer und Hostgruppe 30 für reader. Wir setzen max_writers auf 1, damit wir eine Single-Writer-Hostgruppe für Hostgruppe 10 haben können, an die alle Schreibvorgänge gesendet werden sollen. Dann definieren wir „writer_is_also_reader“ auf 1, was alle Galera-Knoten auch als Leser macht, geeignet für Abfragen, die gleichmäßig auf alle Knoten verteilt werden können. Hostgruppe 9999 ist für offline_hostgroup reserviert, wenn ProxySQL nicht funktionsfähige Galera-Knoten erkennt.
Dann konfigurieren wir unsere MySQL-Server standardmäßig auf Hostgruppe 10:
mysql_servers =
(
{ address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }
)
Mit den obigen Konfigurationen "sieht" ProxySQL unsere Hostgruppen wie folgt:
Dann definieren wir das Abfragerouting durch Abfrageregeln. Basierend auf unserer Anforderung sollten alle Lesevorgänge an alle Galera-Knoten mit Ausnahme des Writers (Hostgruppe 20) gesendet werden, und alles andere wird an Hostgruppe 10 für einen einzelnen Writer weitergeleitet:
mysql_query_rules =
(
{
rule_id=100
active=1
match_pattern="^SELECT .* FOR UPDATE"
destination_hostgroup=10
apply=1
},
{
rule_id=200
active=1
match_pattern="^SELECT .*"
destination_hostgroup=20
apply=1
},
{
rule_id=300
active=1
match_pattern=".*"
destination_hostgroup=10
apply=1
}
)Schließlich definieren wir die MySQL-Benutzer, die durch ProxySQL geleitet werden:
mysql_users =
(
{ username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 },
{ username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }
)Wir setzen transaction_persistent auf 0, damit alle Verbindungen, die von diesen Benutzern kommen, die Abfrageregeln für das Lesen- und Schreiben-Routing respektieren. Andernfalls würden die Verbindungen am Ende auf eine Hostgruppe treffen, was den Zweck des Lastausgleichs zunichte macht. Vergessen Sie nicht, diese Benutzer zuerst auf allen MySQL-Servern anzulegen. Für ClusterControl-Benutzer können Sie die Funktion Verwalten -> Schemas und Benutzer verwenden, um diese Benutzer zu erstellen.
Wir sind jetzt bereit, unseren Container zu starten. Wir werden die ProxySQL-Konfigurationsdatei beim Starten des ProxySQL-Containers als Bind-Mount abbilden. Daher lautet der Ausführungsbefehl:
$ docker run -d \
--name proxysql2 \
--hostname proxysql2 \
--publish 6033:6033 \
--publish 6032:6032 \
--publish 6080:6080 \
--restart=unless-stopped \
-v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf \
severalnines/proxysql:2.0Ändern Sie abschließend die Wordpress-Datenbank, die auf den Port 6033 des ProxySQL-Containers verweist, zum Beispiel:
$ docker run -d \
--name wordpress \
--publish 80:80 \
--restart=unless-stopped \
-e WORDPRESS_DB_HOST=proxysql2:6033 \
-e WORDPRESS_DB_USER=wordpress \
-e WORDPRESS_DB_HOST=passw0rd \
wordpressAn diesem Punkt sieht unsere Architektur in etwa so aus:
Wenn Sie möchten, dass der ProxySQL-Container persistent ist, ordnen Sie /var/lib/proxysql/ einem Docker-Volume zu oder binden Sie Mount, zum Beispiel:
$ docker run -d \
--name proxysql2 \
--hostname proxysql2 \
--publish 6033:6033 \
--publish 6032:6032 \
--publish 6080:6080 \
--restart=unless-stopped \
-v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf \
-v proxysql-volume:/var/lib/proxysql \
severalnines/proxysql:2.0Denken Sie daran, dass die Ausführung mit persistentem Speicher wie oben unsere /root/proxysql/proxysql.cnf beim zweiten Neustart obsolet macht. Dies liegt an der mehrschichtigen ProxySQL-Konfiguration, bei der ProxySQL, wenn /var/lib/proxysql/proxysql.db vorhanden ist, das Laden von Optionen aus der Konfigurationsdatei überspringt und stattdessen alles lädt, was sich in der SQLite-Datenbank befindet (es sei denn, Sie starten den ProxySQL-Dienst mit --initial Flagge). Allerdings muss die nächste ProxySQL-Konfigurationsverwaltung über die ProxySQL-Verwaltungskonsole auf Port 6032 durchgeführt werden, anstatt die Konfigurationsdatei zu verwenden.
Überwachung
Das ProxySQL-Prozessprotokoll protokolliert standardmäßig in Syslog und Sie können es mit dem Standard-Docker-Befehl anzeigen:
$ docker ps
$ docker logs proxysql2Um die aktuelle Hostgruppe zu überprüfen, fragen Sie die Tabelle runtime_mysql_servers ab:
$ docker exec -it proxysql2 mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt='Admin> '
Admin> select hostgroup_id,hostname,status from runtime_mysql_servers;
+--------------+--------------+--------+
| hostgroup_id | hostname | status |
+--------------+--------------+--------+
| 10 | 192.168.0.21 | ONLINE |
| 30 | 192.168.0.21 | ONLINE |
| 30 | 192.168.0.22 | ONLINE |
| 30 | 192.168.0.23 | ONLINE |
| 20 | 192.168.0.22 | ONLINE |
| 20 | 192.168.0.23 | ONLINE |
+--------------+--------------+--------+Wenn der ausgewählte Writer ausfällt, wird er an die offline_hostgroup (HID 9999) übertragen:
Admin> select hostgroup_id,hostname,status from runtime_mysql_servers;
+--------------+--------------+--------+
| hostgroup_id | hostname | status |
+--------------+--------------+--------+
| 10 | 192.168.0.22 | ONLINE |
| 9999 | 192.168.0.21 | ONLINE |
| 30 | 192.168.0.22 | ONLINE |
| 30 | 192.168.0.23 | ONLINE |
| 20 | 192.168.0.23 | ONLINE |
+--------------+--------------+--------+Die obigen Topologieänderungen können im folgenden Diagramm veranschaulicht werden:
Wir haben auch die Benutzeroberfläche für Webstatistiken mit admin-web_enabled=true aktiviert. Um auf die Webbenutzeroberfläche zuzugreifen, gehen Sie einfach zum Docker-Host in Port 6080, zum Beispiel:http://192.168.0.200:8060 und Sie werden mit einem Benutzernamen/Passwort-Popup aufgefordert. Geben Sie die unter admin-stats_credentials definierten Anmeldeinformationen ein und Sie sollten die folgende Seite sehen:
Durch die Überwachung der MySQL-Verbindungspooltabelle können wir eine Übersicht über die Verbindungsverteilung für alle Hostgruppen erhalten:
Admin> select hostgroup, srv_host, status, ConnUsed, MaxConnUsed, Queries from stats.stats_mysql_connection_pool order by srv_host;
+-----------+--------------+--------+----------+-------------+---------+
| hostgroup | srv_host | status | ConnUsed | MaxConnUsed | Queries |
+-----------+--------------+--------+----------+-------------+---------+
| 20 | 192.168.0.23 | ONLINE | 5 | 24 | 11458 |
| 30 | 192.168.0.23 | ONLINE | 0 | 0 | 0 |
| 20 | 192.168.0.22 | ONLINE | 2 | 24 | 11485 |
| 30 | 192.168.0.22 | ONLINE | 0 | 0 | 0 |
| 10 | 192.168.0.21 | ONLINE | 32 | 32 | 9746 |
| 30 | 192.168.0.21 | ONLINE | 0 | 0 | 0 |
+-----------+--------------+--------+----------+-------------+---------+Die obige Ausgabe zeigt, dass Hostgruppe 30 nichts verarbeitet, weil unsere Abfrageregeln diese Hostgruppe nicht als Ziel-Hostgruppe konfiguriert haben.
Die Statistiken zu den Galera-Knoten können in der mysql_server_galera_log-Tabelle eingesehen werden:
Admin> select * from mysql_server_galera_log order by time_start_us desc limit 3\G
*************************** 1. row ***************************
hostname: 192.168.0.23
port: 3306
time_start_us: 1552992553332489
success_time_us: 2045
primary_partition: YES
read_only: NO
wsrep_local_recv_queue: 0
wsrep_local_state: 4
wsrep_desync: NO
wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
error: NULL
*************************** 2. row ***************************
hostname: 192.168.0.22
port: 3306
time_start_us: 1552992553329653
success_time_us: 2799
primary_partition: YES
read_only: NO
wsrep_local_recv_queue: 0
wsrep_local_state: 4
wsrep_desync: NO
wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
error: NULL
*************************** 3. row ***************************
hostname: 192.168.0.21
port: 3306
time_start_us: 1552992553329013
success_time_us: 2715
primary_partition: YES
read_only: NO
wsrep_local_recv_queue: 0
wsrep_local_state: 4
wsrep_desync: NO
wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
error: NULLDie Ergebnismenge gibt die zugehörige MySQL-Variable/den Statusstatus für jeden Galera-Knoten für einen bestimmten Zeitstempel zurück. In dieser Konfiguration haben wir die Galera-Gesundheitsprüfung so konfiguriert, dass sie alle 2 Sekunden ausgeführt wird (monitor_galera_healthcheck_interval=2000). Daher würde die maximale Failover-Zeit etwa 2 Sekunden betragen, wenn eine Topologieänderung am Cluster auftritt.
Referenzen
- Native Galera-Unterstützung für ProxySQL
- HA- und Clustering-Lösung:ProxySQL als intelligenter Router für Galera und Group Replication
- ProxySQL-Docker-Image von Multiplenines
- Überwachen von ProxySQL mit Prometheus und ClusterControl
