W poprzednich wpisach na blogu omawialiśmy tematy dotyczące monitorowania klastra Galera, niezależnie od tego, czy jest to MySQL, czy MariaDB. Chociaż wersje technologii nie różnią się zbytnio, klaster MariaDB ma kilka poważnych zmian od wersji 10.4.2. W tej wersji obsługuje Galera Cluster 4 i ma kilka świetnych nowych funkcji, którym przyjrzymy się w tym poście na blogu.
Dla początkujących, którzy nie znają jeszcze MariaDB Cluster, jest to wirtualnie synchroniczny klaster z wieloma wzorcami dla MariaDB. Jest dostępny tylko w systemie Linux i obsługuje tylko silniki pamięci masowej XtraDB/InnoDB (chociaż istnieje eksperymentalna obsługa MyISAM — zobacz zmienną systemową wsrep_replicate_myisam).
Oprogramowanie to technologia pakietowa, która jest obsługiwana przez MariaDB Server, poprawkę MySQL-wsrep dla MySQL Server i MariaDB Server opracowane przez Codership (obsługuje system operacyjny podobny do systemu Unix) oraz bibliotekę dostawcy Galera wsrep.
Możesz porównać ten produkt z MySQL Group Replication lub z MySQL InnoDB Cluster, którego celem jest zapewnienie wysokiej dostępności. (Chociaż różnią się one w różny sposób co do zasad i podejść do zapewniania HA).
Teraz, gdy omówiliśmy już podstawy, w tym blogu przedstawimy wskazówki, które naszym zdaniem są przydatne podczas monitorowania klastra MariaDB.
Podstawy klastra MariaDB
Kiedy zaczynasz korzystać z Klastra MariaDB, musisz najpierw określić, jaki jest Twój cel i dlaczego wybrałeś Klaster MariaDB. Najpierw musisz zapoznać się z funkcjami i ich zaletami podczas korzystania z klastra MariaDB. Powodem ich zidentyfikowania jest to, że są one zasadniczo tym, co należy monitorować i sprawdzać, aby określić wydajność, normalne warunki zdrowotne i czy działa zgodnie z twoimi planami.
Zasadniczo jest identyfikowany jako brak opóźnień, brak utraconych transakcji, skalowalność odczytu i mniejsze opóźnienia klientów. Wtedy mogą pojawić się pytania typu, w jaki sposób nie powoduje to lagów niewolników lub utraconych transakcji? W jaki sposób sprawia, że odczyt jest skalowalny lub z mniejszymi opóźnieniami po stronie klienta? Obszary te są jednym z kluczowych obszarów, które należy sprawdzać i monitorować, szczególnie w przypadku intensywnego użytkowania produkcji.
Chociaż sam klaster MariaDB można odpowiednio dostosować. Wprowadzenie zmian w zachowaniu domyślnym, takim jak pc.weight lub pc.ignore_quorum, a nawet użycie multiemisji z protokołem UDP dla dużej liczby węzłów, może wpłynąć na sposób monitorowania charakteru klastra MariaDB. Ale z drugiej strony, najistotniejszymi zmiennymi stanu są zazwyczaj twoja pozytywna podszewka, która wie, że stan i przepływ w twojej klastrze ma się dobrze lub jego degradacja pokazuje możliwy problem prowadzący wcześniej do katastrofalnej awarii.
Zawsze monitoruj aktywność serwera (sieć, dysk, obciążenie, pamięć i procesor)
Monitorowanie aktywności serwera może być również złożonym zadaniem, jeśli masz bardzo skomplikowany stos, który jest spleciony z architekturą bazy danych. Jednak w przypadku klastra MariaDB zawsze najlepiej jest, aby węzły były zawsze skonfigurowane tak, aby były dedykowane, ale proste, jak to tylko możliwe. Chociaż nie ogranicza to możliwości korzystania ze wszystkich zapasowych zasobów, poniżej znajdują się wspólne kluczowe obszary, którym należy się przyjrzeć.
Sieć
Galera Cluster 4 oferuje replikację strumieniową jako jedną z kluczowych funkcji i zmian w stosunku do poprzedniej wersji. Ponieważ replikacja strumieniowa rozwiązuje wady, które miała w poprzednich wydaniach, ale umożliwia zarządzanie ponad 2 GB zestawów zapisu od czasu Galera Cluster 4. Pozwala to na fragmentację dużych transakcji i jest wysoce zalecane, aby włączyć to tylko na poziomie sesji. Oznacza to, że monitorowanie aktywności sieciowej jest bardzo ważne i kluczowe dla normalnej aktywności klastra MariaDB. Pomoże to określić, który węzeł miał największy lub najwyższy ruch w sieci w oparciu o okres czasu.
W jaki sposób pomoże Ci to ulepszyć miejsca, w których zidentyfikowano węzły o największym ruchu w sieci? Cóż, zapewnia to pole do poprawy topologii bazy danych lub warstwy architektonicznej klastra bazy danych. Korzystanie z systemów równoważenia obciążenia lub serwera proxy bazy danych umożliwia proaktywne konfigurowanie ruchu w bazie danych, zwłaszcza podczas określania, które konkretne zapisy mają trafić do określonego węzła. Powiedzmy, że z 3 węzłów, jeden jest bardziej zdolny do obsługi dużych i dużych zapytań ze względu na różnice w specyfikacjach sprzętowych. Pozwala to na zarządzanie większą liczbą nakładów inwestycyjnych i poprawę planowania wydajności w miarę zmian wymagań w określonym czasie.
Dysk
Ponieważ aktywność sieciowa ma znaczenie również dla wydajności dysku, zwłaszcza w czasie opróżniania. Najlepiej jest również określić, jak działa zatwierdzony czas i pobieranie po osiągnięciu wysokiego obciążenia szczytowego. Zdarza się, że zaopatrujesz hosta bazy danych, nie tylko poświęcając się działalności klastra Galera, ale także łącząc się z innymi narzędziami, takimi jak docker, serwery proxy SQL, takie jak ProxySQL lub MaxScale. Daje to kontrolę na serwerach o niskim obciążeniu i pozwala wykorzystać dostępne zasoby zapasowe, które można wykorzystać do innych korzystnych celów, zwłaszcza w stosie architektury bazy danych. Gdy już jesteś w stanie określić, który węzeł podczas monitorowania ma najmniejsze obciążenie, ale nadal jest w stanie zarządzać wykorzystaniem IO dysku, możesz wybrać konkretny węzeł, obserwując upływ czasu. Ponownie, nadal zapewnia to lepsze zarządzanie dzięki planowaniu wydajności.
Aktywność procesora, pamięci i obciążenia
Pozwólcie, że pokrótce przedstawię te trzy obszary, na które należy zwrócić uwagę podczas monitorowania. W tej sekcji zawsze najlepiej jest mieć lepszą obserwowalność następujących obszarów na raz. Jest szybszy i łatwiejszy do zrozumienia, zwłaszcza wykluczając wąskie gardło wydajności lub identyfikując błędy, które powodują, że węzły są zawieszone i które mogą również wpływać na inne węzły i możliwość przejścia w dół klastra.
W jaki sposób aktywność procesora, pamięci i obciążenia podczas monitorowania pomaga w klastrze MariaDB? Cóż, jak wspomniałem powyżej, są to jedne z niewielu rzeczy, które mają duży wpływ na codzienne rutynowe kontrole. Teraz pomaga to również określić, czy są to zdarzenia okresowe, czy losowe. Jeśli jest to okresowe, może to być związane z kopiami zapasowymi uruchomionymi w jednym z węzłów Galera lub jest to ogromne zapytanie, które wymaga optymalizacji. Na przykład złe zapytania bez odpowiednich indeksów lub niezrównoważone wykorzystanie pobierania danych, takie jak porównanie ciągów dla tak dużego ciągu. Może to być niezaprzeczalnie nieodpowiednie dla baz danych typu OLTP, takich jak MariaDB Cluster, zwłaszcza jeśli tak naprawdę jest to natura i wymagania Twojej aplikacji. Lepiej korzystaj z innych narzędzi analitycznych, takich jak MariaDB Columnstore lub innych narzędzi do przetwarzania analitycznego innych firm (Apache Spark, Kafka lub MongoDB itp.) do pobierania danych o dużych ciągach i/lub dopasowywania ciągów.
Więc przy monitorowaniu tych wszystkich kluczowych obszarów, pytanie brzmi, jak powinny być monitorowane? Musi być monitorowany co najmniej na minutę. Dzięki udoskonalonemu monitorowaniu, tj. na sekundę metryk zbiorczych, może być zasobożerny i bardzo chciwy pod względem zasobów. Chociaż pół minuty kolekcjonowania jest dopuszczalne, zwłaszcza jeśli Twoje dane i RPO (cel dotyczący punktu odzyskiwania) są bardzo niskie, potrzebujesz bardziej szczegółowych metryk danych w czasie rzeczywistym. Bardzo ważne jest, abyś był w stanie nadzorować cały obraz klastra bazy danych. Poza tym najlepiej i ważne jest, aby zawsze, gdy monitorujesz metryki, masz odpowiednie narzędzie do przyciągnięcia uwagi, gdy coś jest w niebezpieczeństwie, a nawet tylko ostrzeżenia. Korzystanie z odpowiedniego narzędzia, takiego jak ClusterControl, pomaga zarządzać tymi kluczowymi obszarami, które mają być monitorowane. Używam tutaj bezpłatnej lub społecznościowej edycji ClusterControl i pomaga mi monitorować moje węzły bez żadnych kłopotów od instalacji do monitorowania węzłów za pomocą zaledwie kilku kliknięć. Na przykład zobacz zrzuty ekranu poniżej:
Widok jest bardziej precyzyjnym i szybkim przeglądem bieżących wydarzeń. Można również użyć bardziej szczegółowego wykresu,
lub za pomocą bardziej zaawansowanego i bogatszego modelu danych, który obsługuje również język zapytań, dostarcza analizy wydajności klastra MariaDB na podstawie danych historycznych, porównując jego wydajność w odpowiednim czasie. Na przykład
To po prostu zapewnia bardziej widoczne dane. Widzisz więc, jak ważne jest posiadanie odpowiedniego narzędzia podczas monitorowania klastra MariaDB.
Zapewnij wspólne monitorowanie zmiennych statystycznych klastra MariaDB
Od czasu do czasu nie może być nieuniknione, że wersje klastra MariaDB będą generować nowe statystyki do monitorowania lub poprawiać charakter monitorowania bazy danych, dostarczając więcej zmiennych stanu i udoskonalając wartości, na które należy zwracać uwagę. Jak wspomniałem powyżej, używam ClusterControl do monitorowania moich węzłów w tym przykładowym blogu. Nie oznacza to jednak, że jest to najlepsze narzędzie. Mam na myśli to, że PMM firmy Percona jest bardzo bogaty, jeśli chodzi o zbiorcze monitorowanie każdej zmiennej statystycznej, ponieważ zawsze, gdy Klaster MariaDB ma do zaoferowania nowsze zmienne statystyczne, można to wykorzystać, a także zmienić, ponieważ PMM jest narzędziem typu open source. Ogromną zaletą jest to, że masz również całą widoczność swojego klastra MariaDB, ponieważ liczy się każdy aspekt, zwłaszcza w produkcyjnej bazie danych, która obsługuje setki tysięcy żądań na minutę.
Ale przyjrzyjmy się bliżej problemowi. Na co zwrócić uwagę przy tych zmiennych statystycznych? W przypadku klastra MariaDB jest wiele, na które można liczyć, ale skupiając się ponownie na funkcjach i korzyściach, które naszym zdaniem korzystasz z klastra MariaDB, co ma do zaoferowania, skupimy się na tym.
Klaster Galera — kontrola przepływu
Kontrola przepływu klastra MariaDB zapewnia przegląd sposobu działania kondycji replikacji w całym klastrze. Proces replikacji w Galera Cluster wykorzystuje mechanizm sprzężenia zwrotnego, co oznacza, że sygnalizuje wszystkim węzłom w tym klastrze i sygnalizuje, czy węzeł musi wstrzymać lub wznowić replikację zgodnie ze swoimi potrzebami. Zapobiega to również nadmiernemu opóźnianiu się dowolnego węzła, podczas gdy inne stosują przychodzące transakcje. W ten sposób kontrola przepływu spełnia swoją funkcję w Galera. Teraz należy to zauważyć i nie można go przeoczyć podczas monitorowania klastra MariaDB. Jak wspomniano w jednej z korzyści wynikających z korzystania z Klastra MariaDB, jest to, że unika się opóźnień niewolników. Chociaż jest to zbyt naiwne, aby zrozumieć kontrolę przepływu i opóźnienie podrzędne, ale w przypadku kontroli przepływu wpłynie to na wydajność klastra Galera, gdy jest dużo kolejek, a zatwierdzenia lub opróżnianie stron na dysk jest bardzo niskie w przypadku takich problemów z dyskiem lub po prostu uruchomione zapytanie jest złym zapytaniem. Jeśli jesteś początkującym użytkownikiem Galery, możesz zainteresować się tym zewnętrznym postem o tym, czym jest kontrola przepływu w Galerze.
Bajty wysłane/odebrane
Bajty wysłane lub odebrane korelują z aktywnością sieciową, a nawet są jednym z kluczowych obszarów, w których należy patrzeć obok siebie z kontrolą przepływu. Pozwala to określić, który węzeł jest najbardziej dotknięty lub przypisuje problemy z wydajnością w Twoim klastrze Galera. Jest to bardzo ważne, ponieważ możesz sprawdzić, czy nie może nastąpić pogorszenie pod względem sprzętu, takiego jak urządzenie sieciowe lub podstawowe urządzenie pamięci masowej, dla którego synchronizacja brudnych stron może zająć zbyt dużo czasu.
Ładowanie klastra
Cóż, jest to bardziej aktywność bazy danych dotycząca tego, ile zmian lub pobranych danych zostało odpytywanych lub wykonanych do tej pory od czasu działania serwera. Pomaga wykluczyć, jakiego rodzaju zapytania mają największy wpływ na wydajność klastra bazy danych. Pozwala to zapewnić miejsce na ulepszenia, zwłaszcza w zakresie równoważenia obciążenia żądań bazy danych. Korzystanie z ProxySQL pomaga w bardziej wyrafinowanym i szczegółowym podejściu do routingu zapytań. Chociaż MaxScale również oferuje tę funkcję, ProxySQL ma większą szczegółowość, chociaż ma również pewien wpływ na wydajność lub koszty. Wpływ pojawia się, gdy masz tylko jeden serwer ProxySQL jako serwer proxy SQL do obliczania routingu zapytań i może mieć problemy z ciągłym dużym ruchem. Koszt, jeśli dodasz więcej węzłów ProxySQL, aby zrównoważyć większy ruch, który bazowy KeepAlived. Chociaż jest to idealna kombinacja, ale można ją uruchomić przy niskich kosztach, dopóki nie będzie potrzebna. Jak jednak będziesz w stanie określić w razie potrzeby, prawda? To pytanie pozostaje tutaj, więc uważne oko do monitorowania tych kluczowych obszarów jest bardzo ważne, nie tylko dla obserwowalności, ale także dla poprawy wydajności klastra bazy danych w miarę upływu czasu.
W związku z tym istnieje mnóstwo zmiennych, na które należy zwrócić uwagę w klastrze MariaDB. Najważniejszą rzeczą, którą musisz wziąć pod uwagę, jest narzędzie, którego używasz do monitorowania klastra bazy danych. Jak wspomniano wcześniej, wolę używać bezpłatnej licencji ClusterControl (Community Edition) tutaj w tym blogu, ponieważ zapewnia mi ona więcej możliwości elastycznego patrzenia na klaster Galera. Zobacz przykład poniżej,
Zakreśliłem lub zakreśliłem na czerwono te karty, które pozwalają mi wizualnie nadzorować stan mojego klastra MariaDB. Załóżmy, że jeśli Twoja aplikacja od czasu do czasu zachłannie korzysta z replikacji strumieniowej i wysyła dużą liczbę fragmentów (duży transfer sieciowy) w celu zapewnienia interaktywności klastra, najlepiej jest określić, jak dobrze Twoje węzły radzą sobie z obciążeniem. Szczególnie podczas testów warunków skrajnych przed wprowadzeniem określonych zmian w aplikacji zawsze najlepiej jest spróbować przetestować zarządzanie wydajnością produktu aplikacji i określić, czy obecne węzły bazy danych i projekt mogą obsłużyć obciążenie wymagań aplikacji.
Nawet w wersji społecznościowej ClusterControl jestem w stanie zebrać szczegółowe i bardziej precyzyjne wyniki dotyczące stanu mojego klastra MariaDB. Zobacz poniżej,
W ten sposób należy podejść do monitorowania klastra MariaDB. Perfekcyjna wizualizacja jest zawsze łatwiejsza i szybsza w zarządzaniu. Kiedy sprawy pójdą na marne, nie możesz sobie pozwolić na utratę produktywności, a przestoje mogą mieć wpływ na Twój biznes. Chociaż posiadanie darmowego dostępu nie zapewnia luksusu i komfortu podczas zarządzania bazami danych o dużym natężeniu ruchu, posiadanie alarmów, powiadomień i zarządzania bazą danych w jednym obszarze to proste dodatki, które może zrobić ClusterControl.
Wnioski
Klaster MariaDB nie jest tak prosty w monitorowaniu w porównaniu z tradycyjnymi asynchronicznymi konfiguracjami typu master-slave MySQL/MariaDB. Działa to inaczej i musisz mieć odpowiednie narzędzia, aby określić, co się dzieje i co dzieje się w klastrze bazy danych. Zawsze przygotuj z wyprzedzeniem planowanie wydajności przed uruchomieniem klastra MariaDB bez wcześniejszego odpowiedniego monitorowania. Zawsze najlepiej jest, aby obciążenie i aktywność bazy danych były znane przed katastrofą.
