ProxySQL ist ein bekannter Load-Balancer in der MySQL-Welt - er verfügt über eine Reihe großartiger Funktionen, mit denen Sie die Kontrolle über Ihren Datenverkehr übernehmen und ihn so gestalten können, wie Sie es für richtig halten. Es kann auf viele verschiedene Arten bereitgestellt werden – dedizierte Knoten, zusammen mit Anwendungshosts, Silo-Ansatz – alles hängt von der genauen Umgebung und den Geschäftsanforderungen ab. Die allgemeine Herausforderung besteht darin, dass Sie in den meisten Fällen möchten, dass Ihre ProxySQL-Knoten dieselbe Konfiguration enthalten. Wenn Sie Ihren Cluster skalieren und ProxySQL einen neuen Server hinzufügen, möchten Sie, dass dieser Server auf allen ProxySQL-Instanzen sichtbar ist, nicht nur auf der aktiven. Dies führt zu der Frage:Wie stellen Sie sicher, dass Sie die Konfiguration über alle ProxySQL-Knoten hinweg synchron halten?
Sie können versuchen, alle Knoten von Hand zu aktualisieren, was definitiv nicht effizient ist. Sie können auch eine Art Infrastruktur-Orchestrierungstools wie Ansible oder Chef verwenden, um die Konfiguration über die Knoten hinweg in einem bekannten Zustand zu halten, indem Sie die Änderungen nicht direkt auf ProxySQL vornehmen, sondern über das Tool, das Sie zum Organisieren Ihrer Umgebung verwenden.
Wenn Sie ClusterControl verwenden, enthält es eine Reihe von Funktionen, mit denen Sie die Konfiguration zwischen ProxySQL-Instanzen synchronisieren können, aber diese Lösung hat ihre Nachteile - es ist eine manuelle Aktion, an die Sie denken müssen nach einer Konfigurationsänderung ausführen. Wenn Sie dies vergessen, könnten Sie eine böse Überraschung erleben, wenn beispielsweise keepalived Virtual IP auf die nicht aktualisierte ProxySQL-Instanz verschiebt.
Keine dieser Methoden ist einfach oder 100 % zuverlässig, und die Situation tritt ein, wenn die ProxySQL-Knoten unterschiedliche Konfigurationen haben und potenziell gefährlich sein könnten.
Glücklicherweise bietet ProxySQL eine Lösung für dieses Problem – ProxySQL Cluster. Die Idee ist ziemlich einfach – Sie können eine Liste von ProxySQL-Instanzen definieren, die miteinander kommunizieren und andere über die Version der Konfiguration informieren, die jede von ihnen enthält. Die Konfiguration ist versioniert, daher führt jede Änderung einer Einstellung auf einem beliebigen Knoten zu einer Erhöhung der Konfigurationsversion - dies löst die Konfigurationssynchronisierung aus und die neue Version der Konfiguration wird verteilt und auf alle Knoten angewendet, die den ProxySQL-Cluster bilden.
Mit der aktuellen Version von ClusterControl können Sie mühelos ProxySQL-Cluster einrichten. Bei der Bereitstellung von ProxySQL sollten Sie die Option „Natives Clustering verwenden“ für alle Knoten aktivieren, die Teil des Clusters sein sollen.
Sobald Sie das getan haben, sind Sie ziemlich fertig – der Rest passiert unter die Motorhaube.
MySQL [(none)]> select * from proxysql_servers;
+------------+------+--------+----------------+
| hostname | port | weight | comment |
+------------+------+--------+----------------+
| 10.0.0.131 | 6032 | 0 | proxysql_group |
| 10.0.0.132 | 6032 | 0 | proxysql_group |
+------------+------+--------+----------------+
2 rows in set (0.001 sec)Auf beiden Servern wurde die Proxysql_servers-Tabelle richtig mit den Hostnamen der Knoten gesetzt, die den Cluster bilden. Wir können auch überprüfen, ob die Konfigurationsänderungen ordnungsgemäß über den Cluster weitergegeben werden:
Wir haben die Einstellung „Max. Verbindungen“ auf einem der ProxySQL-Knoten (10.0 .0.131) und wir können überprüfen, ob der andere Knoten (10.0.0.132) dieselbe Konfiguration sieht:
Wenn der Prozess debuggt werden muss, können wir uns jederzeit darum kümmern das ProxySQL-Protokoll (normalerweise in /var/lib/proxysql/proxysql.log), wo wir Informationen wie diese sehen:
2020-11-26 13:40:47 [INFO] Cluster: detected a new checksum for mysql_servers from peer 10.0.0.131:6032, version 11, epoch 1606398059, checksum 0x441378E48BB01C61 . Not syncing yet ...
2020-11-26 13:40:49 [INFO] Cluster: detected a peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060, diff_check 3. Own version: 9, epoch: 1606398022. Proceeding with remote sync
2020-11-26 13:40:50 [INFO] Cluster: detected a peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060, diff_check 4. Own version: 9, epoch: 1606398022. Proceeding with remote sync
2020-11-26 13:40:50 [INFO] Cluster: detected peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060
2020-11-26 13:40:50 [INFO] Cluster: Fetching MySQL Servers from peer 10.0.0.131:6032 started. Expected checksum 0x441378E48BB01C61
2020-11-26 13:40:50 [INFO] Cluster: Fetching MySQL Servers from peer 10.0.0.131:6032 completed
2020-11-26 13:40:50 [INFO] Cluster: Fetching checksum for MySQL Servers from peer 10.0.0.131:6032 before proceessing
2020-11-26 13:40:50 [INFO] Cluster: Fetching checksum for MySQL Servers from peer 10.0.0.131:6032 successful. Checksum: 0x441378E48BB01C61
2020-11-26 13:40:50 [INFO] Cluster: Writing mysql_servers table
2020-11-26 13:40:50 [INFO] Cluster: Writing mysql_replication_hostgroups table
2020-11-26 13:40:50 [INFO] Cluster: Loading to runtime MySQL Servers from peer 10.0.0.131:6032Dies ist das Protokoll von 10.0.0.132, in dem wir deutlich sehen können, dass eine Konfigurationsänderung für die Tabelle mysql_servers auf 10.0.0.131 erkannt und dann auf 10.0.0.132 synchronisiert und angewendet wurde, wodurch sie synchronisiert wurde mit dem anderen Knoten im Cluster.
Wie Sie sehen können, ist das Clustern von ProxySQL eine einfache und dennoch effiziente Methode, um sicherzustellen, dass die Konfiguration synchron bleibt, und hilft erheblich dabei, größere ProxySQL-Bereitstellungen zu verwenden. Teilen Sie uns in den Kommentaren Ihre Erfahrungen mit ProxySQL-Clustering mit.
