Dodaliśmy kilka nowych pulpitów nawigacyjnych dla MySQL w naszej najnowszej wersji ClusterControl 1.7.0. - a w naszym poprzednim blogu pokazaliśmy, jak monitorować serwer proxy SQL za pomocą Prometheus i ClusterControl.
W tym blogu przyjrzymy się pulpitowi nawigacyjnemu Przegląd MySQL.
Dlatego włączyliśmy monitorowanie oparte na agentach na karcie Pulpit nawigacyjny, aby rozpocząć zbieranie metryk do węzłów. Zwróć uwagę, że podczas włączania monitorowania opartego na agencie możesz ustawić „Interwał usuwania (sekundy) ” i „Przechowywanie danych (dni) ”. Interwał skrobania to miejsce, w którym chcesz ustawić, jak agresywnie Prometheus będzie zbierać dane z celu, a Przechowywanie danych to czas, przez jaki chcesz przechowywać dane zebrane przez Prometheus, zanim zostaną usunięte.
Po włączeniu możesz określić, który klaster ma agentów, a który monitoruje bez agentów.
W porównaniu z podejściem bez agentów szczegółowość danych na wykresach będzie wyższa w przypadku agentów.
Wykresy MySQL
Najnowsza wersja ClusterControl 1.7.0 (którą można pobrać bezpłatnie — ClusterControl Community) zawiera następujące pulpity nawigacyjne MySQL, dla których można zbierać informacje dotyczące serwerów MySQL. Są to przegląd MySQL, wskaźniki MySQL InnoDB, schemat wydajności MySQL i replikacja MySQL.
Omówimy szczegółowo wykresy dostępne w panelu Przegląd MySQL.
Panel informacyjny MySQL
Ten pulpit nawigacyjny zawiera zwykle ważne zmienne lub informacje dotyczące stanu Twojego węzła MySQL. Wykresy zawarte na tym pulpicie nawigacyjnym są specyficzne dla węzła wybranego podczas przeglądania pulpitów nawigacyjnych, jak pokazano poniżej:
Składa się z 26 wykresów, ale możesz nie potrzebować ich wszystkich podczas diagnozowania problemów. Jednak te wykresy zapewniają istotną reprezentację ogólnych metryk dla twoich serwerów MySQL. Przyjrzyjmy się podstawowym, ponieważ są to prawdopodobnie najczęstsze rzeczy, na które rutynowo patrzy administrator.
Pierwsze cztery wykresy pokazane powyżej wraz z czasem działania MySQL, liczbą zapytań na sekundę i informacjami o puli buforów są najbardziej podstawowymi wskaźnikami, jakich możemy potrzebować. Oto ich reprezentacje z wykresów wyświetlonych powyżej:
- Połączenia MySQL
W tym miejscu chcesz sprawdzić całkowitą liczbę połączeń klientów przydzielonych do tej pory w określonym czasie. - Aktywność wątków klienta MySQL
Czasami twój serwer MySQL może być bardzo zajęty. Na przykład można oczekiwać, że w określonym czasie nastąpi nagły wzrost ruchu i chcesz monitorować aktywność uruchomionych wątków. Ten wykres jest naprawdę ważny. Może się zdarzyć, że wydajność zapytania spadnie, jeśli na przykład duża aktualizacja spowoduje, że inne wątki będą czekać na uzyskanie blokady. Doprowadziłoby to do zwiększenia liczby uruchomionych wątków. Współczynnik chybienia pamięci podręcznej jest obliczany jako Threads_created/Connections. - Pytania dotyczące MySQL
Są to zapytania działające w określonym czasie. Wątek może być transakcją złożoną z wielu zapytań i może to być dobry wykres do obejrzenia. - Pamięć podręczna wątków MySQL
Ten wykres przedstawia wartość thread_cache_size, wątków, które są buforowane (wątki, które są ponownie używane) i wątków, które są tworzone (nowe wątki). Możesz sprawdzić na tym wykresie takie przypadki, jak potrzeba dostrojenia zapytań odczytu, gdy zauważysz dużą liczbę połączeń przychodzących, a liczba utworzonych wątków szybko się zwiększa. Na przykład, jeśli twój Threads_running / thread_cache_size> 2, to zwiększenie thread_cache_size może dać wzrost wydajności twojego serwera. Zwróć uwagę, że tworzenie i niszczenie wątków jest kosztowne. Jednak w ostatnich wersjach MySQL (>=5.6.8) ta zmienna ma domyślnie automatyczne rozmiary, co można uznać za nietknięte.
Kolejne cztery wykresy to obiekty tymczasowe MySQL, wybrane typy MySQL, sortowania MySQL i wolne zapytania MySQL. Te wykresy są ze sobą powiązane, szczególnie jeśli diagnozujesz długo działające zapytania i duże zapytania, które wymagają optymalizacji.
- Obiekty tymczasowe MySQL
Ten wykres byłby dobrym źródłem, na którym można polegać, jeśli chcesz monitorować długo działające zapytania, które w efekcie będą wykorzystywały dysk zamiast tymczasowych tabel lub plików w pamięci. To dobre miejsce, aby zacząć szukać okresowych zapytań, które mogą się sumować, tworząc problemy z miejscem na dysku, szczególnie w nietypowych czasach. - Wybrane typy MySQL
Jednym ze źródeł złej wydajności są zapytania korzystające z pełnych złączeń, skanowanie tabel, wybór zakresu, który nie używa żadnych indeksów. Ten wykres pokazywałby, jak działa Twoje zapytanie i co na liście od pełnych złączeń do złączeń pełnego zakresu, wybierz zakres, skanowanie tabeli ma najwyższe trendy. - Sortowanie MySQL
Diagnozowanie zapytań korzystających z sortowania oraz tych, których zakończenie zajmuje dużo czasu. - Powolne zapytania MySQL
Trendy Twoich powolnych zapytań są gromadzone na tym wykresie. Jest to bardzo przydatne, zwłaszcza przy diagnozowaniu, jak często zapytania są powolne. Jakie rzeczy należy dostroić? Może to być zbyt mała pula buforów, tabele, które nie mają indeksów i przechodzą skanowanie całej tabeli, logiczne kopie zapasowe działające zgodnie z nieoczekiwanym harmonogramem itp. Korzystanie z naszego Monitora zapytań w ClusterControl wraz z tym wykresem jest korzystne, ponieważ pomaga określić wolne zapytania.
Kolejne wykresy, które omówimy, to więcej aktywności sieciowej, blokad tabel i podstawowej pamięci wewnętrznej, którą MySQL zużywa podczas aktywności MySQL.
- Przerwane połączenia MySQL
Na tym wykresie zostanie wyrenderowana liczba przerwanych połączeń. Obejmuje to przerwanych klientów, na przykład w przypadku nagłego zamknięcia sieci lub przerwania lub przerwania połączenia internetowego. Rejestruje również przerwane połączenia lub próby, takie jak błędne hasła lub złe pakiety po nawiązaniu połączenia od klienta. - Blokady tabeli MySQL
Trendy dla tabel, które żądają blokady tabeli, która została przyznana natychmiast, oraz dla tabel, które żądają blokady, która nie została uzyskana natychmiast. Na przykład, jeśli masz blokady na poziomie tabeli w tabelach MyISAM i przychodzące żądania tej samej tabeli, nie można ich przyznać natychmiast. - Ruch w sieci MySQL
Ten wykres przedstawia trendy aktywności sieci przychodzącej i wychodzącej na serwerze MySQL. „Przychodzące” to dane odbierane przez serwer MySQL, a „Wychodzące” to dane wysyłane lub przesyłane przez serwer z serwera MySQL. Ten wykres najlepiej sprawdzać, jeśli chcesz monitorować ruch sieciowy, zwłaszcza podczas diagnozowania ruchu jest umiarkowany, ale zastanawiasz się, dlaczego ma bardzo dużo przesyłanych danych wychodzących, takich jak na przykład dane BLOB. - Godzinowe korzystanie z sieci MySQL
To samo, co ruch sieciowy, który pokazuje dane odebrane i wysłane. Zwróć uwagę, że jest on oparty na „na godzinę” i oznaczony jako „ostatni dzień”, który nie będzie zgodny z okresem wybranym w selektorze dat. - Omówienie pamięci wewnętrznej MySQL
Ten wykres jest znany doświadczonym administratorom baz danych MySQL. Każda z tych legend na wykresie słupkowym jest bardzo ważna, zwłaszcza jeśli chcesz monitorować wykorzystanie pamięci, wykorzystanie puli buforów lub adaptacyjny rozmiar indeksu skrótu.
Poniższe wykresy przedstawiają liczniki, na których administrator może polegać, np. sprawdzanie statystyk, statystyka wyboru, wstawiania, aktualizacji, liczba wykonanych statusów głównych, liczba wykonanych POKAŻ ZMIENNYCH, sprawdzenie jeśli masz złe zapytania wykonujące skanowanie tabel lub tabele nie używające indeksów, przeglądając liczniki read_* itp.
- Najważniejsze liczniki poleceń (godzinowe)
Są to wykresy, które prawdopodobnie będziesz musiał sprawdzić za każdym razem, gdy chciałbyś zobaczyć statystyki swoich wstawek, usunięć, aktualizacji, wykonanych poleceń, takich jak zbieranie listy procesów, status slave, status show (statystyki kondycji serwera MySQL ), i wiele więcej. Jest to dobre miejsce, jeśli chcesz sprawdzić, jakie liczniki poleceń MySQL są najwyższe i czy potrzebne jest dostrojenie wydajności lub optymalizacja zapytań. Może również pozwolić ci zidentyfikować, które polecenia działają agresywnie, a nie są potrzebne. - Programy obsługi MySQL
Często administrator danych sprawdza te programy obsługi i sprawdza, jak zapytania są wykonywane na serwerze MySQL. Zasadniczo ten wykres obejmuje liczniki z interfejsu Handler API MySQL. Najczęstsze liczniki obsługi dla DBA dla API przechowywania w MySQL to Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd i Handler_read_rnd_next. Istnieje wiele programów obsługi MySQL, które można sprawdzić. Możesz przeczytać o nich w dokumentacji tutaj. - Programy obsługi transakcji MySQL
Jeśli Twój serwer MySQL używa transakcji XA, instrukcji SAVEPOINT, ROLLBACK TO SAVEPOINT. Zatem ten wykres jest dobrym punktem odniesienia do obejrzenia. Możesz również użyć tego wykresu do monitorowania wszystkich wewnętrznych zatwierdzeń Twojego serwera. Zwróć uwagę, że licznik dla Handler_commit zwiększa się nawet dla instrukcji SELECT, ale różni się od instrukcji insert/update/delete, które trafiają do dziennika binarnego podczas wywołania instrukcji COMMIT.
Następny wykres pokaże trendy dotyczące stanów procesów i ich godzinowego wykorzystania. Legenda wykresu słupkowego zawiera wiele kluczowych punktów, które sprawdziłby administrator. Napotkano problemy z miejscem na dysku, problemy z połączeniem i sprawdź, czy pula połączeń działa zgodnie z oczekiwaniami, wysokie we/wy dysku, problemy z siecią itp.
- Stany procesu/stany najwyższego procesu co godzinę
Na tym wykresie możesz monitorować stany górnych wątków zapytań uruchomionych na liście procesów. Jest to bardzo pouczające i pomocne w przypadku takich zadań DBA, w których można sprawdzić tutaj wszelkie zaległe statusy, które wymagają rozwiązania. Na przykład otwieranie stołów stan jest bardzo wysoki, a jego wartość minimalna jest prawie zbliżona do wartości maksymalnej. Może to wskazywać, że musisz dostosować table_open_cache. Jeśli statystyki jest wysoki i zauważasz spowolnienie serwera, może to oznaczać, że Twój serwer jest powiązany z dyskiem i może być konieczne rozważenie zwiększenia puli buforów. Jeśli masz dużo tworzenia tabeli tmp wtedy może być konieczne sprawdzenie powolnego dziennika i zoptymalizowanie obraźliwych zapytań. Możesz sprawdzić instrukcję, aby zobaczyć pełną listę stanów wątków MySQL tutaj.
Następny wykres, który będziemy sprawdzać, dotyczy pamięci podręcznej zapytań, pamięci podręcznej definicji tabeli MySQL, jak często MySQL otwiera pliki systemowe.
- Pamięć/aktywność pamięci podręcznej zapytań MySQL
Te wykresy są ze sobą powiązane. Jeśli masz query_cache_size <> 0 i query_cache_type <> 0, ten wykres może być pomocny. Jednak w nowszych wersjach MySQL pamięć podręczna zapytań została oznaczona jako przestarzała, ponieważ pamięć podręczna zapytań MySQL powoduje problemy z wydajnością. Możesz nie potrzebować tego w przyszłości. Najnowsza wersja MySQL 8.0 ma drastyczne ulepszenia; ma tendencję do zwiększania wydajności, ponieważ zawiera kilka strategii obsługi informacji o pamięci podręcznej w buforach pamięci. - Otwory plików MySQL
Ten wykres pokazuje trend dla otwieranych plików od czasu działania serwera MySQL, ale nie obejmuje plików takich jak gniazda czy potoki. Nie obejmuje również plików otwieranych przez silnik pamięci masowej, ponieważ mają one swój własny licznik, którym jest Innodb_num_open_files. - Otwarte pliki MySQL
Na tym wykresie chcesz sprawdzić aktualnie przechowywane otwarte pliki InnoDB, bieżące otwarte pliki MySQL oraz zmienną open_files_limit. - Stan otwartej pamięci podręcznej tabeli MySQL
Jeśli masz ustawioną bardzo niską wartość table_open_cache, ten wykres pokaże ci te tabele, które nie działają w pamięci podręcznej (nowo otwarte tabele) lub zostały pominięte z powodu przepełnienia. Jeśli napotkasz wysoką liczbę lub zbyt wiele statusu „Otwieranie tabel” na liście procesów, ten wykres posłuży jako odniesienie do ustalenia tego. Dzięki temu dowiesz się, czy istnieje potrzeba zwiększenia zmiennej table_open_cache. - Otwarte tabele MySQL
Względem stanu otwartej pamięci podręcznej tabeli MySQL, ten wykres jest przydatny w pewnych sytuacjach, np. gdy chcesz określić, czy istnieje potrzeba zwiększenia pamięci podręcznej table_open_cache lub obniżenia jej, jeśli zauważysz duży wzrost liczby otwartych tabel lub zmiennej stanu Open_tables . Zwróć uwagę, że table_open_cache może zająć dużo miejsca w pamięci, więc musisz ustawić to ostrożnie, szczególnie w systemach produkcyjnych. - Pamięć podręczna definicji tabeli MySQL
Jeśli chcesz sprawdzić liczbę zmiennych statusu Open_table_definitions i Opened_table_definitions, ten wykres jest tym, czego potrzebujesz. W nowszych wersjach MySQL (>=5.6.8) może nie być konieczne zmienianie wartości tej zmiennej i używanie wartości domyślnej, ponieważ ma ona funkcję automatycznego zmiany rozmiaru.
Wniosek
Dodatek SCUMM w najnowszej wersji ClusterControl 1.7.0 zapewnia znaczące nowe korzyści dla wielu kluczowych zadań DBA. Nowe wykresy mogą pomóc w łatwym ustaleniu przyczyny problemów, z którymi zwykle musieliby się uporać administratorzy baz danych lub administratorzy, i pomóc w szybszym znalezieniu odpowiednich rozwiązań.
Chętnie poznamy Twoje wrażenia i przemyślenia na temat korzystania z ClusterControl 1.7.0 z SCUMM (który możesz pobrać bezpłatnie - ClusterControl Community).
W części 2 tego bloga omówię efektywne monitorowanie replikacji MySQL za pomocą pulpitów nawigacyjnych SCUMM.
