MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

ClusterControl:wprowadzenie do nowego monitora zapytań

ClusterControl 1.9.0 został wydany 16 lipca 2021 roku z wieloma nowymi funkcjami wprowadzonymi do systemu. Funkcje te obejmują Redis Management and Monitoring, nowy system monitorowania zapytań oparty na agentach dla MySQL i PostgreSQL, ulepszenia pgBackRest, a także kilka innych ulepszeń wymienionych tutaj. Jesteśmy bardzo podekscytowani, ponieważ jest to nasza druga duża wersja na 2021 r. po ClusterControl 1.8.2.

Jeśli jesteś nowy w ClusterControl, Query Monitor jest jedną z naszych przydatnych funkcji, dzięki której możesz uzyskać informacje o obciążeniu Twojej bazy danych. Monitor zapytań zawiera podsumowanie przetwarzania zapytań we wszystkich węzłach w klastrze, co staje się niezbędne, gdy zauważysz lub doświadczysz spadku wydajności. Nie wszystkie funkcje monitorowania zapytań są takie same dla każdego typu bazy danych, na przykład monitor zapytań oparty na MySQL różni się od monitora zapytań dla PostgreSQL.

Wydajność na najwyższym poziomie nie jest usprawiedliwieniem, zwłaszcza gdy używasz aplikacji o znaczeniu krytycznym, poza zapewnieniem najlepszego doświadczenia użytkownika.

W tym wpisie na blogu omówimy, co oferuje nowy Monitor zapytań i przejdziemy przez niektóre kroki, jak włączyć go zarówno dla systemów opartych na MySQL, jak i PostgreSQL. Bez zbędnych ceregieli zacznijmy!

Nasz nowy monitor zapytań MySQL

Jeśli już zaktualizowałeś tę nową wersję, prawdopodobnie zauważysz niektóre zmiany w interfejsie. Nowy Monitor zapytań będzie miał dodatkową kartę o nazwie Przegląd. Przegląd zapytań to miejsce, w którym można uzyskać ogólny przegląd wszystkich zapytań dotyczących klastra bazy danych. W przypadku instancji baz danych opartych na MySQL należy włączyć parametr „performance_schema” dla wszystkich instancji MySQL przed zainstalowaniem agenta zapytań. Po kliknięciu karty Przegląd zapytań zobaczysz następujący zrzut ekranu:

Jeśli nie włączyłeś „schematu wydajności”, nie będziesz mógł korzystać z tego pulpitu nawigacyjnego. Możesz włączyć parametr przez Cluster -> Manage -> Configurations i edytować plik /etc/my.cnf dla wszystkich hostów. Zaktualizuj wartość do następującej:

performance_schema =WŁ

Po wykonaniu tej czynności należy wykonać stopniowe ponowne uruchomienie klastra z listy działań klastra, aby zmiana zaczęła obowiązywać. Bez stopniowego restartu nie można zainstalować agenta zapytań.

Oczywiście można to również zrobić ręcznie z węzłów bazy danych, to zależy od twoich preferencji. Jeśli wybierzesz ręczny sposób, możesz SSH do swojej instancji bazy danych i edytować /etc/my.cnf.

 Teraz powinieneś zauważyć następujący zrzut ekranu po zakończeniu restartu kroczącego i wszystkich co musisz zrobić, to kliknąć Zainstaluj Query Monitor Agent:

Powinno minąć tylko trochę czasu, zanim zobaczysz nowy pulpit nawigacyjny Przegląd zapytań jak na poniższym zrzucie ekranu:

W naszym nowym panelu Przegląd zapytań jest kilka zmiennych, które możesz monitorować i pobierać metryki. Tutaj możesz zobaczyć przepustowość, współbieżność, średnie opóźnienie, błąd, a także listę zapytań na dole. Wyjaśnienie każdego z nich jest następujące:

  • Przepustowość — zapytania na sekundę (q/s) 

    • Ogólna możliwość przetwarzania danych mierzonych w zapytaniach na sekundę, transakcjach na sekundę lub średnim czasie odpowiedzi .

  • Współbieżność — czas blokady (s)

    • Liczba równoczesnych zapytań, zwłaszcza zapytania INSERT. Jest mierzony w sekundach.

  • Średni czas oczekiwania — średni czas zapytania (s)

    • Rozkład opóźnień instrukcji uruchomionych w tej instancji MySQL.

  • Błędy — Błędy (s)

    • Liczba błędów zapytań na sekundę dla klastra.

Możesz wybrać, dla której instancji bazy danych chcesz zobaczyć metryki, a także przedział czasowy od 15 minut do 4 godzin dla każdej z nich. Dzięki tej opcji możesz łatwo zidentyfikować, co dzieje się w tym konkretnym przypadku.

Na dole pulpitu możesz zauważyć, że znajduje się lista zapytań, które są aktualnie uruchomione dla Twojego klastra. Tutaj możesz zobaczyć informacje dotyczące skrótu zapytania, schematu, liczby, wierszy, a także czasu wykonania.

W przeciwieństwie do starszej wersji (1.8.2), jest to całkowicie nowy pulpit nawigacyjny i będzie bardzo przydatny, gdy chcesz mieć przegląd klastra. Dzięki tym metrykom będziesz mógł podjąć niezbędne działania, jeśli zauważysz, że wydajność klastra nie jest optymalna.

Nowy monitor zapytań dla PostgreSQL

Ten sam proces należy wykonać dla PostgreSQL:po uaktualnieniu ClusterControl do wersji 1.9.0 będziesz musiał zainstalować agenta monitora zapytań, zanim uzyskasz metryki dla Przeglądu zapytań. Zobaczysz dane wyjściowe podobne do tego poniżej:

Jednak dla PostgreSQL nie musisz włączać żadnego parametru jak ty Jeśli potrzebujesz baz danych opartych na MySQL, możesz od razu zainstalować agenta z pulpitu nawigacyjnego. Instalacja powinna chwilę potrwać, zanim zobaczysz panel Przegląd zapytań, jak poniżej.

Jak widać, kokpit różni się nieco od MySQL pulpit nawigacyjny, w którym są tylko 2 metryki, którymi są przepustowość i średnie opóźnienie. Podobnie jak pulpit nawigacyjny Przegląd zapytań oparty na MySQL, możesz również wybrać instancję bazy danych, dla której chcesz wyświetlić metryki, a także zakres czasowy.

Możesz również zobaczyć listę zapytań poniżej danych, jak pokazano na powyższym zrzucie ekranu. Na liście zapytań możesz zobaczyć skrót, schemat, liczbę, wiersze i czas wykonania każdego zapytania.

Ostateczne myśli

Uważamy, że nowy monitor zapytań jest bardzo przydatny, gdy chcesz zobaczyć, co dzieje się z twoimi zapytaniami w instancji bazy danych. Wyobraź sobie, że masz kilka węzłów:możesz łatwo przełączyć instancję bazy danych z Przeglądu zapytań, aby zobaczyć metryki. Dzięki tej opcji możesz dokładnie wiedzieć, co dzieje się w każdej z Twoich instancji bazy danych.

W przypadku instancji opartych na MySQL pamiętaj, aby włączyć/włączyć „performance_schema” dla każdej instancji bazy danych przed zainstalowaniem agenta zapytań i przejściem do przeglądu.

Co myślisz o naszym nowym Monitorze zapytań? Podoba Ci się i uważasz, że jest przydatny? Daj nam znać w sekcji komentarzy poniżej.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Zrozumienie skutków dużych opóźnień w rozwiązaniach MySQL i MariaDB o wysokiej dostępności

  2. Funkcje numeryczne MariaDB (pełna lista)

  3. Uruchamianie MariaDB w konfiguracji chmury hybrydowej

  4. Jak działa POKAŻ ZESTAW ZNAKÓW w MariaDB

  5. Dlaczego baza danych MySQL uległa awarii? Uzyskaj informacje dzięki nowej ramce MySQL Freeze Frame