ClusterControl to doskonałe narzędzie do wdrażania i zarządzania klastrami baz danych - jeśli jesteś w MySQL, możesz łatwo wdrożyć klastry oparte zarówno na tradycyjnej replikacji MySQL master-slave, Galera Cluster lub MySQL NDB Cluster. Aby osiągnąć wysoką dostępność, wdrożenie klastra nie wystarczy. Węzły mogą (i najprawdopodobniej będą) wyłączać się, a Twój system musi być w stanie dostosować się do tych zmian.
Ta adaptacja może mieć miejsce na różnych poziomach. W aplikacji można zaimplementować jakąś logikę - sprawdzałaby stan węzłów klastra i kierowała ruch do tych, które są w danym momencie osiągalne. Możesz także zbudować warstwę proxy, która zaimplementuje wysoką dostępność w Twoim systemie. W tym poście na blogu chcielibyśmy podzielić się kilkoma wskazówkami, jak możesz to osiągnąć za pomocą ClusterControl.
Wdrażanie HAProxy za pomocą ClusterControl
Standardem jest HAProxy - jeden z najpopularniejszych serwerów proxy używanych w połączeniu z MySQL (ale oczywiście nie tylko). ClusterControl obsługuje wdrażanie i monitorowanie węzłów HAProxy. Pomaga również wdrożyć wysoką dostępność samego serwera proxy za pomocą funkcji keepalive.
Wdrożenie jest dość proste — musisz wybrać lub wpisać adres IP hosta, na którym zostanie zainstalowany HAProxy, wybrać port, zasady równoważenia obciążenia, zdecydować, czy ClusterControl powinien użyć istniejącego repozytorium lub najnowszego kodu źródłowego do wdrożenia HAProxy. Możesz także wybrać, które węzły zaplecza chcesz uwzględnić w konfiguracji proxy i czy powinny być aktywne, czy zapasowe.
Domyślnie instancja HAProxy wdrożona przez ClusterControl będzie działać w klastrze MySQL (NDB), klastrze Galera, replikacji strumieniowej PostgreSQL i replikacji MySQL. W przypadku replikacji master-slave, ClusterControl może skonfigurować dwa detektory, jeden tylko do odczytu, a drugi do odczytu i zapisu. Aplikacje będą wtedy musiały wysyłać odczyty i zapisy do odpowiednich portów. W przypadku replikacji z wieloma wzorcami ClusterControl skonfiguruje standardowe równoważenie obciążenia TCP w oparciu o algorytm równoważenia połączeń (np. w przypadku Galera Cluster, w którym wszystkie węzły można zapisywać).
Keepalived służy do dodawania wysokiej dostępności do warstwy proxy. Jeśli masz co najmniej dwa węzły HAProxy w swoim systemie, możesz zainstalować Keepalived z interfejsu użytkownika ClusterControl.
Będziesz musiał wybrać dwa węzły HAProxy i zostaną one skonfigurowane jako para aktywna - w trybie gotowości. Wirtualny adres IP zostanie przypisany do aktywnego serwera, aw przypadku niepowodzenia zostanie ponownie przypisany do zapasowego serwera proxy. W ten sposób możesz po prostu połączyć się z VIPem, a wszystkie Twoje zapytania zostaną skierowane do aktualnie aktywnego i działającego węzła HAProxy.
Więcej szczegółów na temat konfiguracji elementów wewnętrznych można znaleźć w naszym samouczku HAProxy.
Wdrażanie ProxySQL za pomocą ClusterControl
Chociaż HAProxy jest solidnym serwerem proxy i bardzo popularnym wyborem, brakuje mu świadomości bazy danych, np. podziału odczytu i zapisu. Jedynym sposobem na zrobienie tego w HAProxy jest stworzenie dwóch backendów i nasłuchiwanie na dwóch portach - jeden dla odczytów i jeden dla zapisów. Zwykle jest to w porządku, ale wymaga wprowadzenia zmian w aplikacji — aplikacja musi zrozumieć, co to jest odczyt, a co zapis, a następnie skierować te zapytania do właściwego portu. O wiele łatwiej byłoby po prostu połączyć się z pojedynczym portem i pozwolić serwerowi proxy zdecydować, co dalej - jest to coś, czego HAProxy nie może zrobić, ponieważ to, co robi, to tylko routing pakietów - nie jest przeprowadzana inspekcja pakietów, a zwłaszcza nie ma zrozumienie protokołu MySQL.
ProxySQL rozwiązuje ten problem - posługuje się protokołem MySQL i może (między innymi) dokonywać podziału odczytu i zapisu poprzez potężne reguły zapytań i kierować przychodzący ruch MySQL według różnych kryteriów. Instalacja ProxySQL z ClusterControl jest prosta - chcesz przejść do sekcji Zarządzaj -> Load Balancer i wypełnić zakładkę „Wdróż ProxySQL” wymaganymi danymi.
Krótko mówiąc, musimy wybrać, gdzie ProxySQL zostanie zainstalowany, jakiego użytkownika administracyjnego i hasła powinien mieć, którego użytkownika monitorującego powinien używać do łączenia się z backendami MySQL i weryfikowania ich statusu oraz monitorowania stanu. W ClusterControl możesz utworzyć nowego użytkownika do użycia przez aplikację - możesz zdecydować o jego nazwie, haśle, dostępie do jakich baz danych oraz jakie uprawnienia MySQL będzie miał ten użytkownik. Taki użytkownik zostanie utworzony zarówno po stronie MySQL, jak i ProxySQL. Drugą opcją, bardziej odpowiednią dla istniejącej infrastruktury, jest wykorzystanie istniejących użytkowników baz danych. Musisz podać nazwę użytkownika i hasło, a taki użytkownik zostanie utworzony tylko w ProxySQL.
Na koniec musisz odpowiedzieć na pytanie:czy korzystasz z transakcji niejawnych? Rozumiemy przez to transakcje rozpoczęte przez uruchomienie SET autocommit=0; Jeśli go użyjesz, ClusterControl skonfiguruje ProxySQL, aby wysyłał cały ruch do mastera. Jest to wymagane, aby zapewnić, że ProxySQL będzie poprawnie obsługiwał transakcje w ProxySQL 1.3.x i wcześniejszych. Jeśli nie użyjesz SET autocommit=0 do utworzenia nowej transakcji, ClusterControl skonfiguruje podział odczytu/zapisu.
ProxySQL, jak każdy serwer proxy, może stać się pojedynczym punktem awarii i musi być zbędny, aby osiągnąć wysoką dostępność. Jest na to kilka metod. Jednym z nich jest kolokacja ProxySQL na węzłach internetowych. Pomysł polega na tym, że przez większość czasu proces ProxySQL będzie działał dobrze, a przyczyną jego niedostępności jest awaria całego węzła. W takim przypadku, jeśli ProxySQL jest skolokowany z węzłem sieciowym, nie wyrządzono wiele szkody, ponieważ ten konkretny węzeł sieciowy również nie będzie dostępny.
Inną metodą jest użycie Keepalive w podobny sposób, jak w przypadku HAProxy.
Więcej informacji na temat konfiguracji elementów wewnętrznych można znaleźć w naszym samouczku ProxySQL.
