Warstwa proxy między aplikacjami a bazami danych zwykle składa się z wielu węzłów proxy, co zapewnia wysoką dostępność. Nie inaczej jest w przypadku ProxySQL. ProxySQL, podobnie jak inne nowoczesne serwery proxy, może być używany do budowania złożonej logiki dla zapytań routingu. Możesz dodać reguły zapytań, aby wysyłać zapytania do określonych hostów, możesz buforować zapytania, możesz dodawać i usuwać serwery zaplecza lub zarządzać użytkownikami, którzy mogą łączyć się z ProxySQL i MySQL. Jednak liczne węzły ProxySQL w warstwie proxy wprowadzają kolejny problem - synchronizację między rozproszonymi instancjami. Wszelkie reguły lub inna logika muszą być zsynchronizowane między instancjami, aby zapewnić, że zachowują się w ten sam sposób. Nawet jeśli nie wszystkie serwery proxy obsługują ruch, nadal działają jako rezerwa. Na wypadek, gdyby musieli przejąć pracę, nie chcesz żadnych niespodzianek, jeśli używana instancja nie ma najnowszych zmian w konfiguracji.
Dość kłopotliwe jest zapewnienie tego ręcznie - ręczne wprowadzanie zmian we wszystkich węzłach. Do zarządzania konfiguracjami możesz wykorzystać narzędzia takie jak Ansible, Chef lub Puppet, ale proces synchronizacji musi być zakodowany i przetestowany. ClusterControl może Ci w tym pomóc dzięki opcji synchronizacji konfiguracji między instancjami ProxySQL, ale może również skonfigurować i zarządzać innymi komponentami wymaganymi do wysokiej dostępności, np. Wirtualny adres IP. Jednak począwszy od wersji 1.4.2, ProxySQL oferuje natywny mechanizm klastrowania i synchronizacji konfiguracji. W tym poście na blogu omówimy, jak to skonfigurować, korzystając z kombinacji działań podejmowanych w interfejsie administracyjnym wiersza poleceń ClusterControl i ProxySQL.
Przede wszystkim rzućmy okiem na typowe środowisko replikacji wdrożone przez ClusterControl.
Jak widać na zrzucie ekranu, jest to konfiguracja replikacji MySQL z trzema instancjami ProxySQL. Wysoka dostępność ProxySQL jest realizowana poprzez Keepalived i Virtual IP, które są zawsze przypisane do jednego z węzłów ProxySQL. Aby skonfigurować klastrowanie ProxySQL, musimy wykonać kilka kroków. Najpierw musimy zdefiniować, którego użytkownika ProxySQL powinien używać do wymiany informacji między węzłami. Zdefiniujmy nowy nad istniejącym użytkownikiem administracyjnym:
Następnie musimy zdefiniować tego użytkownika w ustawieniach admin-cluster_password i admin-cluster_username.
Dokonano tego tylko na jednym z węzłów (10.0.0.126). Zsynchronizujmy tę zmianę konfiguracji z pozostałymi węzłami ProxySQL.
Jak już wspomnieliśmy, ClusterControl umożliwia synchronizację konfiguracji między węzłami ProxySQL w zaledwie kilku krokach. Kiedy zadanie zakończyło synchronizację 10.0.0.127 z 10.0.0.126, jest tylko ostatni węzeł, który musimy zsynchronizować.
Następnie musimy dokonać niewielkiej zmiany w administracyjnym interfejsie wiersza poleceń ProxySQL, który jest zwykle dostępny na porcie 6032. Musimy utworzyć wpisy w tabeli „proxysql_servers”, które zdefiniują węzły w naszym klastrze ProxySQL.
mysql> INSERT INTO proxysql_servers (hostname) VALUES ('10.0.0.126'), ('10.0.0.127'), ('10.0.0.128');
Query OK, 3 rows affected (0.00 sec)mysql> LOAD PROXYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE PROXYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.01 sec)Po załadowaniu zmiany do środowiska wykonawczego, ProxySQL powinien rozpocząć synchronizację węzłów. Jest kilka miejsc, w których możesz śledzić stan klastra.
mysql> SELECT * FROM stats_proxysql_servers_checksums;
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| hostname | port | name | version | epoch | checksum | changed_at | updated_at | diff_check |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| 10.0.0.128 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_query_rules | 2 | 1539772933 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_servers | 4 | 1539772933 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_users | 2 | 1539772933 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | proxysql_servers | 2 | 1539773835 | 0x8EB13E2B48C3FDB0 | 1539773835 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_query_rules | 3 | 1539773719 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_servers | 5 | 1539773719 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_users | 3 | 1539773719 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | proxysql_servers | 2 | 1539773812 | 0x8EB13E2B48C3FDB0 | 1539773813 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_query_rules | 1 | 1539770578 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_servers | 3 | 1539771053 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_users | 1 | 1539770578 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | proxysql_servers | 2 | 1539773546 | 0x8EB13E2B48C3FDB0 | 1539773546 | 1539773916 | 0 |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
18 rows in set (0.00 sec)Tabela stats_proxysql_servers_checksums zawiera m.in. listę węzłów w klastrze, synchronizowane tabele, wersje oraz sumę kontrolną tabeli. Jeśli suma kontrolna nie jest zgodna, ProxySQL spróbuje pobrać najnowszą wersję z peera klastra. Bardziej szczegółowe informacje na temat zawartości tej tabeli można znaleźć w dokumentacji ProxySQL.
Innym źródłem informacji o procesie jest dziennik ProxySQL (domyślnie znajduje się on w /var/lib/proxysql/proxysql.log).
2018-10-17 11:00:25 [INFO] Cluster: detected a new checksum for mysql_query_rules from peer 10.0.0.126:6032, version 2, epoch 1539774025, checksum 0xD615D5416F61AA72 . Not syncing yet …
2018-10-17 11:00:27 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 3. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 4. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 started
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 completed
2018-10-17 11:00:28 [INFO] Cluster: Loading to runtime MySQL Query Rules from peer 10.0.0.126:6032
2018-10-17 11:00:28 [INFO] Cluster: Saving to disk MySQL Query Rules from peer 10.0.0.126:6032Jak widać, mamy tutaj informację, że wykryto nową sumę kontrolną i że proces synchronizacji został uruchomiony.
Zatrzymajmy się tutaj na chwilę i porozmawiajmy o tym, jak ProxySQL obsługuje aktualizacje konfiguracji z wielu źródeł. Przede wszystkim ProxySQL śledzi sumy kontrolne, aby wykryć zmianę konfiguracji. Przechowuje również, kiedy to się stało – te dane są przechowywane jako znacznik czasu, więc ma rozdzielczość jednej sekundy. ProxySQL ma dwie zmienne, które również wpływają na sposób synchronizacji zmian.
Cluster_check_interval_ms - określa jak często ProxySQL powinien sprawdzać zmiany w konfiguracji. Domyślnie jest to 1000 ms.
Cluster_mysql_servers_diffs_before_sync - mówi nam, ile razy kontrola powinna wykryć zmianę konfiguracji, zanim zostanie zsynchronizowana. Ustawienie domyślne to 3.
Oznacza to, że nawet jeśli dokonasz zmiany w konfiguracji na tym samym hoście, jeśli będziesz robił to rzadziej niż 4 sekundy, pozostałe węzły ProxySQL mogą nie być w stanie jej zsynchronizować, ponieważ nowa zmiana pojawi się przed poprzednią został zsynchronizowany. Oznacza to również, że jeśli wprowadzasz zmiany w konfiguracji na wielu instancjach ProxySQL, powinieneś je robić z co najmniej 4-sekundową przerwą między nimi, ponieważ w przeciwnym razie niektóre zmiany zostaną utracone, a w rezultacie konfiguracje będą się różnić. Na przykład dodajesz Serwer1 na Proxy1 , a po 2 sekundach dodajesz Serwer2 na Proxy2 . Wszystkie inne serwery proxy odrzucą zmianę na Proxy1, ponieważ wykryją, że Proxy2 ma nowszą konfigurację. 4 sekundy po zmianie na Proxy2, wszystkie proxy (w tym Proxy1) pobierzą konfigurację z Proxy2.
Ponieważ komunikacja wewnątrz klastra nie jest synchroniczna i jeśli węzeł ProxySQL, w którym wprowadzono zmiany, nie powiódł się, zmiany mogą nie zostać zreplikowane na czas. Najlepszym podejściem jest wprowadzenie tej samej zmiany na dwóch węzłach ProxySQL. W ten sposób, o ile oba nie zawiodą dokładnie w tym samym czasie, jeden z nich będzie mógł propagować nową konfigurację.
Warto również zauważyć, że topologia klastra ProxySQL może być dość elastyczna. W naszym przypadku mamy trzy węzły, wszystkie mają trzy wpisy w tabeli proxysql_servers. Takie węzły tworzą klaster, w którym można pisać do dowolnego węzła, a zmiany będą propagowane. Dodatkowo możliwe jest dodawanie zewnętrznych węzłów, które działałyby w trybie „tylko do odczytu”, co oznacza, że synchronizowałyby tylko zmiany dokonane w klastrze „core”, ale nie będą propagowały zmian, które zostały wykonane bezpośrednio na siebie. Wszystko, czego potrzebujesz na nowym węźle, to skonfigurowanie tylko „rdzeniowych” węzłów klastra na serwerach proxysql_servers, a w rezultacie połączy się z tymi węzłami i uzyska zmiany danych, ale nie będzie odpytywany przez resztę klastra za zmiany w jego konfiguracji. Ta konfiguracja może być wykorzystana do stworzenia źródła prawdy z kilkoma węzłami w klastrze i innymi węzłami ProxySQL, które po prostu pobierają konfigurację z głównego „rdzenia” klastra.
Oprócz tego klaster ProxySQL obsługuje automatyczne ponowne dołączanie węzłów - zsynchronizują one swoją konfigurację podczas uruchamiania. Można go również łatwo skalować, dodając więcej węzłów.
Mamy nadzieję, że ten wpis na blogu daje wgląd w to, jak można skonfigurować klaster ProxySQL. Klaster ProxySQL będzie przezroczysty dla ClusterControl i nie wpłynie na żadne operacje, które możesz chcieć wykonać z interfejsu użytkownika ClusterControl.
