W pierwszej części serii pokazaliśmy, jak wdrożyć konfigurację replikacji MySQL z ProxySQL z WHM i cPanel. W tej części pokażemy niektóre operacje po wdrożeniu dotyczące konserwacji, zarządzania, przełączania awaryjnego, a także zalety w porównaniu z samodzielną konfiguracją.
Zarządzanie użytkownikami MySQL
Po włączeniu tej integracji zarządzanie użytkownikami MySQL będzie musiało odbywać się z WHM lub cPanel. W przeciwnym razie tabela mysql_users ProxySQL nie byłaby synchronizowana z konfiguracją dla naszego wzorca replikacji. Załóżmy, że utworzyliśmy już użytkownika o nazwie fewn_user1 (nazwa użytkownika MySQL jest automatycznie poprzedzona przez cPanel, aby zachować zgodność z ograniczeniami MySQL) i chcielibyśmy przypisać do bazy danych fewn_db1 jak poniżej:
Powyższe spowoduje wyświetlenie następującej tabeli mysql_users w ProxySQL:
Jeśli chcesz tworzyć zasoby MySQL poza cPanel, możesz użyć ClusterControl -> Zarządzaj -> Schematy i użytkownicy funkcji, a następnie zaimportuj użytkownika bazy danych do ProxySQL, przechodząc do ClusterControl -> Węzły -> wybierz węzeł ProxySQL -> Użytkownicy -> Importuj użytkowników .
Moduł Proxysqlhook, którego używamy do synchronizacji użytkowników ProxySQL, wysyła logi debugowania do /usr/local/cpanel/logs/error_log. Użyj tego pliku, aby sprawdzić i zrozumieć, co dzieje się za kulisami. Następujące wiersze pojawią się w pliku dziennika cPanel, jeśli zainstalowaliśmy aplikację internetową o nazwie Zikula przy użyciu Softaculous:
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****Zobaczysz kilka powtarzających się linii, takich jak „Sprawdzanie, czy {użytkownik bazy danych} istnieje”, ponieważ WHM tworzy wielu użytkowników/hostów MySQL dla każdego żądania utworzenia użytkownika bazy danych. W naszym przykładzie WHM utworzy tych 3 użytkowników:
ProxySQL potrzebuje tylko nazwy użytkownika, hasła i informacji o domyślnej grupie hostów podczas dodawania użytkownika. Dlatego linie kontrolne są po to, aby uniknąć wielokrotnego wstawiania tego samego użytkownika.
Jeśli chcesz zmodyfikować moduł i wprowadzić w nim jakieś ulepszenia, nie zapomnij ponownie zarejestrować modułu, uruchamiając następujące polecenie na serwerze WHM:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookMonitorowanie zapytań i buforowanie
Dzięki ProxySQL możesz monitorować wszystkie zapytania przychodzące z aplikacji, które przeszły lub przechodzą przez nią. Standardowy WHM nie zapewnia takiego poziomu szczegółowości w monitorowaniu zapytań MySQL. Poniżej przedstawiono wszystkie zapytania MySQL, które zostały przechwycone przez ProxySQL:
Dzięki ClusterControl możesz łatwo wyszukać najczęściej powtarzające się zapytania i buforować je za pomocą funkcji pamięci podręcznej zapytań ProxySQL. Użyj menu „Uporządkuj według”, aby posortować zapytania według „Gwiazdki zliczania”, najedź kursorem na zapytanie, które chcesz zapisać w pamięci podręcznej, i kliknij znajdujący się pod nim przycisk „Zapytaj w pamięci podręcznej”. Pojawi się następujące okno dialogowe:
Zestaw wyników zapytań z pamięci podręcznej będzie przechowywany i obsługiwany przez sam ProxySQL, zmniejszając liczbę trafień do zaplecza, co odciąży cały klaster replikacji MySQL. Implementacja pamięci podręcznej zapytań ProxySQL zasadniczo różni się od pamięci podręcznej zapytań MySQL. Jest to pamięć podręczna oparta na czasie i wygaśnie po przekroczeniu limitu czasu o nazwie „Cache TTL”. W tej konfiguracji chcielibyśmy buforować powyższe zapytanie przez 5 sekund (5000 ms) od trafienia do grupy czytników, w której docelowa grupa hostów to 20.
Podział i równoważenie odczytu/zapisu
Słuchając domyślnego portu MySQL 3306, ProxySQL działa jak sam serwer MySQL. Posługuje się protokołami MySQL zarówno na froncie, jak i zapleczu. Reguły zapytań zdefiniowane przez ClusterControl podczas konfigurowania ProxySQL automatycznie podzielą wszystkie odczyty (^SELECT .* w języku Regex) na grupę hostów 20, która jest grupą czytników, a reszta zostanie przekazana do grupy hostów zapisujących 10, jak pokazano w następująca sekcja reguł zapytań:
Dzięki tej architekturze nie musisz się martwić o dzielenie zapytań odczytu/zapisu, ponieważ ProxySQL zrobi to za Ciebie. Użytkownicy mają minimalne lub żadne zmiany w kodzie, co pozwala użytkownikom hostingu na korzystanie ze wszystkich aplikacji i funkcji dostarczanych przez WHM i cPanel natywnie, podobnie do łączenia się z samodzielną konfiguracją MySQL.
Jeśli chodzi o równoważenie połączeń, jeśli masz więcej niż jeden aktywny węzeł w danej grupie hostów (np. grupa hostów czytnika 20 w tym przykładzie), ProxySQL automatycznie rozłoży obciążenie między nimi w oparciu o szereg kryteriów - wagi, opóźnienie replikacji, używane połączenia , całkowite obciążenie i opóźnienie. Wiadomo, że ProxySQL jest bardzo dobry w środowisku o wysokiej współbieżności dzięki implementacji zaawansowanego mechanizmu puli połączeń. Cytowany z wpisu na blogu ProxySQL, ProxySQL nie tylko implementuje trwałe połączenie, ale także multipleksowanie połączeń. W rzeczywistości ProxySQL może obsłużyć setki tysięcy klientów, a jednocześnie przekazywać cały ich ruch do kilku połączeń do backendu. Tak więc ProxySQL może obsłużyć N połączeń klientów i M połączeń backendowych , gdzie N> M (nawet N tysięcy razy większe niż M).
Przełączanie awaryjne i odzyskiwanie MySQL
Dzięki ClusterControl zarządzającemu klastrem replikacji, przełączanie awaryjne jest wykonywane automatycznie, jeśli włączone jest automatyczne odzyskiwanie. W przypadku awarii głównej:
- ClusterControl wykryje i zweryfikuje główną awarię poprzez klienta MySQL, SSH i ping.
- ClusterControl poczeka 3 sekundy przed rozpoczęciem procedury przełączania awaryjnego.
- ClusterControl będzie promować najbardziej aktualne urządzenie podrzędne na następnego urządzenia nadrzędnego.
- Jeśli stary master wróci do trybu online, zostanie uruchomiony jako tylko do odczytu, bez udziału w aktywnej replikacji.
- Od użytkowników zależy, co stanie się ze starym mistrzem. Można go ponownie wprowadzić do łańcucha replikacji za pomocą funkcji „Rebuild Replication Slave” w ClusterControl.
- ClusterControl podejmie próbę wykonania głównego przełączenia awaryjnego tylko raz. Jeśli to się nie powiedzie, wymagana jest interwencja użytkownika.
Cały proces przełączania awaryjnego można monitorować w ClusterControl -> Aktywność -> Zadania -> Przełączanie awaryjne na nowy system główny jak pokazano poniżej:
Podczas przełączania awaryjnego wszystkie połączenia z serwerami baz danych będą umieszczane w kolejce w ProxySQL. Nie zostaną zakończone do czasu przekroczenia limitu czasu, kontrolowanego przez mysql-default_query_timeout zmienna, która wynosi 86400000 milisekund lub 24 godziny. W tym momencie aplikacje najprawdopodobniej nie zobaczą błędów ani awarii w bazie danych, ale kompromisem jest zwiększone opóźnienie w ramach konfigurowalnego progu.
W tym momencie ClusterControl przedstawi poniższą topologię:
Jeśli chcielibyśmy zezwolić staremu wzorcowi na przyłączenie się z powrotem do replikacji po jej uruchomieniu i udostępnieniu, musielibyśmy odbudować go jako urządzenie podrzędne, przechodząc do ClusterControl -> Węzły -> wybierz stary wzorzec -> Odbuduj replikację Niewolnik -> wybierz nowego mistrza -> Kontynuuj . Po zakończeniu przebudowy powinieneś uzyskać następującą topologię (uwaga:192.168.0.32 jest teraz nadrzędną):
Konsolidacja serwerów i skalowanie bazy danych
Dzięki tej architekturze możemy skonsolidować wiele serwerów MySQL, które znajdują się na każdym serwerze WHM, w jedną konfigurację replikacji. W miarę rozwoju można skalować więcej węzłów bazy danych lub mieć wiele klastrów replikacji, które obsługują je wszystkie i są zarządzane przez jeden serwer ClusterControl. Poniższy diagram architektury ilustruje, czy mamy dwa serwery WHM podłączone do jednego klastra replikacji MySQL za pośrednictwem pliku gniazda ProxySQL:
Powyższe pozwala nam oddzielić dwie najważniejsze warstwy w naszym systemie hostingowym - aplikację (front-end) i bazę danych (back-end). Jak zapewne wiesz, wspólne ulokowanie MySQL na serwerze WHM często prowadzi do wyczerpania zasobów, ponieważ MySQL wymaga ogromnej alokacji pamięci RAM z góry, aby się dobrze uruchomić i działać (głównie w zależności od innodb_buffer_pool_size zmienny). Biorąc pod uwagę, że miejsce na dysku jest wystarczające, przy powyższej konfiguracji możesz mieć więcej kont hostingowych hostowanych na serwer, gdzie wszystkie zasoby serwera mogą być wykorzystywane przez aplikacje warstwy front-end.
Skalowanie klastra replikacji MySQL będzie znacznie prostsze dzięki architekturze oddzielnej warstwy. Jeśli powiedzmy, że master wymaga konserwacji w górę (aktualizacja pamięci RAM, dysku twardego, RAID, NIC), możemy przełączyć rolę mastera na inny slave (ClusterControl -> Nodes -> wybierz slave -> Promuj urządzenie podrzędne ), a następnie wykonaj zadanie konserwacji bez wpływu na usługę MySQL jako całość. W przypadku operacji skalowania w poziomie (dodawanie większej liczby urządzeń podrzędnych) można to wykonać bez wpływu na urządzenie nadrzędne, wykonując przemieszczanie bezpośrednio z dowolnego aktywnego urządzenia podrzędnego. Dzięki ClusterControl możesz nawet ustawić nowe urządzenie podrzędne z istniejącej kopii zapasowej MySQL (tylko zgodne z PITR):
Odbudowa slave'a z kopii zapasowej nie przyniesie dodatkowego obciążenia dla mastera. ClusterControl skopiuje wybrany plik kopii zapasowej z serwera ClusterControl do węzła docelowego i wykona tam przywracanie. Po zakończeniu węzeł połączy się z masterem i zacznie pobierać wszystkie brakujące transakcje od czasu przywracania i dogonić mastera. Gdy jest opóźniony, ProxySQL nie uwzględni węzła w zestawie równoważenia obciążenia, dopóki opóźnienie replikacji nie będzie krótsze niż 10 sekund (konfigurowalne podczas dodawania tabeli mysql_servers przez interfejs administracyjny ProxySQL).
Ostateczne myśli
ProxySQL rozszerza możliwości WHM cPanel w zarządzaniu replikacją MySQL. Dzięki ClusterControl zarządzającemu klastrem replikacji wszystkie złożone zadania związane z zarządzaniem klastrem replikacji są teraz łatwiejsze niż kiedykolwiek wcześniej.
