ProxySQL jest dobrze znanym systemem równoważenia obciążenia w świecie MySQL — zawiera wspaniały zestaw funkcji, które pozwalają przejąć kontrolę nad ruchem i kształtować go w dowolny sposób. Może być wdrażany na wiele różnych sposobów - dedykowane węzły, kolokacja z hostami aplikacji, podejście silosowe - wszystko zależy od konkretnego środowiska i wymagań biznesowych. Typowym wyzwaniem jest to, że w większości przypadków chcesz, aby węzły ProxySQL zawierały tę samą konfigurację. Jeśli skalujesz klaster i dodasz nowy serwer do ProxySQL, chcesz, aby ten serwer był widoczny we wszystkich instancjach ProxySQL, a nie tylko w aktywnym. Prowadzi to do pytania - jak upewnić się, że konfiguracja jest zsynchronizowana we wszystkich węzłach ProxySQL?
Możesz spróbować zaktualizować wszystkie węzły ręcznie, co zdecydowanie nie jest wydajne. Możesz także użyć pewnego rodzaju narzędzi do aranżacji infrastruktury, takich jak Ansible lub Chef, aby utrzymać konfigurację we wszystkich węzłach w znanym stanie, dokonując modyfikacji nie bezpośrednio w ProxySQL, ale za pomocą narzędzia, którego używasz do organizowania środowiska.
Jeżeli korzystasz z ClusterControl, jest on wyposażony w zestaw funkcji, które pozwalają na synchronizację konfiguracji pomiędzy instancjami ProxySQL, ale to rozwiązanie ma swoje wady - jest to ręczna akcja, musisz pamiętać o wykonaj go po zmianie konfiguracji. Jeśli zapomnisz o tym, możesz być niemiłą niespodzianką, jeśli na przykład keepalived przeniesie wirtualny adres IP do niezaktualizowanej instancji ProxySQL.
Żadna z tych metod nie jest prosta ani w 100% niezawodna, a sytuacja ma miejsce, gdy węzły ProxySQL mają różne konfiguracje i mogą być potencjalnie niebezpieczne.
Na szczęście ProxySQL zawiera rozwiązanie tego problemu - ProxySQL Cluster. Pomysł jest dość prosty - możesz zdefiniować listę instancji ProxySQL, które będą ze sobą rozmawiać i informować innych o wersji konfiguracji, jaką zawiera każda z nich. Konfiguracja jest wersjonowana, dlatego każda modyfikacja dowolnego ustawienia w dowolnym węźle spowoduje zwiększenie wersji konfiguracji - powoduje to synchronizację konfiguracji, a nowa wersja konfiguracji jest dystrybuowana i stosowana we wszystkich węzłach tworzących klaster ProxySQL.
Najnowsza wersja ClusterControl umożliwia bezproblemową konfigurację klastrów ProxySQL. Podczas wdrażania ProxySQL należy zaznaczyć opcję „Użyj natywnego klastrowania” dla wszystkich węzłów, które mają być częścią klastra.
Gdy to zrobisz, wszystko jest gotowe – reszta dzieje się kaptur.
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)Na obu serwerach tabela proxysql_servers została prawidłowo ustawiona z nazwami hostów węzłów tworzących klaster. Możemy również sprawdzić, czy zmiany konfiguracji są prawidłowo propagowane w klastrze:
Zwiększyliśmy ustawienie Maksymalna liczba połączeń na jednym z węzłów ProxySQL (10.0 .0.131) i możemy sprawdzić, czy drugi węzeł (10.0.0.132) zobaczy tę samą konfigurację:
W razie potrzeby debugowania procesu zawsze możemy skorzystać z dziennik ProxySQL (zazwyczaj znajduje się w /var/lib/proxysql/proxysql.log), gdzie zobaczymy informacje takie jak:
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:6032To jest dziennik z 10.0.0.132, w którym wyraźnie widać, że zmiana konfiguracji dla tabeli mysql_servers została wykryta w 10.0.0.131, a następnie została zsynchronizowana i zastosowana w 10.0.0.132, dzięki czemu jest zsynchronizowana z drugim węzłem w klastrze.
Jak widać, klastrowanie ProxySQL jest łatwym, ale wydajnym sposobem zapewnienia synchronizacji konfiguracji i znacznie pomaga w korzystaniu z większych wdrożeń ProxySQL. Daj nam znać w komentarzach, jakie są Twoje doświadczenia z klastrowaniem ProxySQL.
