Większość administratorów baz danych od czasu do czasu przeprowadza kontrole stanu swoich baz danych. Zwykle zdarzało się to codziennie lub co tydzień. Wcześniej omawialiśmy, dlaczego takie kontrole są ważne i co powinny obejmować.
Aby upewnić się, że Twoje systemy są w dobrym stanie, musisz przejrzeć całkiem sporo informacji – statystyki hostów, statystyki MySQL, statystyki obciążenia, stan kopii zapasowych, pakiety baz danych, logi i tak dalej. Takie dane powinny być dostępne w każdym odpowiednio monitorowanym środowisku, choć czasami są rozproszone w wielu lokalizacjach - możesz mieć jedno narzędzie do monitorowania stanu MySQL, inne narzędzie do zbierania statystyk systemowych, może zestaw skryptów np. do sprawdzania stanu Twoje kopie zapasowe. To sprawia, że kontrole stanu są znacznie bardziej czasochłonne niż powinny – administrator DBA musi połączyć różne elementy, aby zrozumieć stan systemu.
Zintegrowane narzędzia, takie jak ClusterControl, mają tę zaletę, że wszystkie bity znajdują się w tym samym miejscu (lub w tej samej aplikacji). Nie oznacza to jednak, że znajdują się obok siebie — mogą znajdować się w różnych sekcjach interfejsu użytkownika, a administrator danych może potrzebować trochę czasu na klikanie w interfejsie, aby uzyskać dostęp do wszystkich interesujących danych.
Cała idea tworzenia raportów operacyjnych polega na umieszczeniu wszystkich najważniejszych danych w jednym dokumencie, który można szybko przejrzeć, aby zrozumieć stan baz danych.
Raporty operacyjne są dostępne z menu Menu boczne -> Raporty operacyjne:
Po przejściu tam zobaczysz listę raportów utworzonych ręcznie lub automatycznie, na podstawie wstępnie zdefiniowanego harmonogramu:
Jeśli chcesz ręcznie utworzyć nowy raport, użyj opcji „Utwórz”. Wybierz typ raportu, nazwę klastra (w przypadku raportu dla klastra), odbiorców poczty e-mail (opcjonalnie – jeśli chcesz, aby raport został dostarczony do Ciebie) i gotowe:
Raporty można również zaplanować w celu regularnego tworzenia:
Obecnie dostępnych jest 5 typów raportów:
- Raport dostępności – Wszystkie klastry.
- Raport kopii zapasowej – Wszystkie klastry.
- Raport zmian schematu — tylko klaster oparty na MySQL/MariaDB.
- Codzienny raport systemowy – według klastra.
- Raport uaktualnienia pakietu – według klastra.
Raport dostępności
Raporty dostępności skupiają się na, no cóż, dostępności. Zawiera trzy sekcje. Po pierwsze, podsumowanie dostępności:
Możesz zobaczyć informacje o statystykach dostępności Twoich baz danych, typie klastra, całkowitym czasie działania i przestoju, aktualnym stanie klastra i ostatniej zmianie tego stanu.
Kolejna sekcja zawiera więcej szczegółów na temat dostępności dla każdego klastra. Poniższy zrzut ekranu pokazuje tylko jeden z klastrów baz danych:
Możemy zobaczyć, kiedy stan przełączenia węzła i jakie było przejście. To miłe miejsce, aby sprawdzić, czy ostatnio wystąpiły jakieś problemy z klastrem. Podobne dane są pokazane w trzeciej części tego raportu, gdzie można przejrzeć historię zmian stanu klastra.
Raport kopii zapasowej
Drugi rodzaj raportu to raport obejmujący kopie zapasowe wszystkich klastrów. Zawiera dwie sekcje - podsumowanie kopii zapasowej i szczegóły kopii zapasowej, z których pierwsza zasadniczo zawiera krótkie podsumowanie, kiedy utworzono ostatnią kopię zapasową, czy zakończyła się pomyślnie lub nie, status weryfikacji kopii zapasowej, wskaźnik powodzenia i okres przechowywania:
ClusterControl udostępnia również przykłady zasad tworzenia kopii zapasowych, jeśli wykryje, że którykolwiek z monitorowanych klastrów baz danych działa bez zaplanowanej kopii zapasowej lub skonfigurowanego opóźnionego urządzenia podrzędnego. Dalej są szczegóły kopii zapasowej:
Możesz także sprawdzić listę kopii zapasowych wykonanych w klastrze wraz z ich stanem, typem i rozmiarem w określonym interwale. Jest to tak blisko, że możesz mieć pewność, że kopie zapasowe działają poprawnie bez uruchamiania pełnego testu odzyskiwania. Zdecydowanie zalecamy wykonywanie takich testów co jakiś czas. Dobra wiadomość jest taka, że ClusterControl obsługuje przywracanie i weryfikację w oparciu o MySQL na samodzielnym hoście w opcji Kopia zapasowa -> Przywróć kopię zapasową.
Codzienny raport systemowy
Ten typ raportu zawiera szczegółowe informacje o konkretnym klastrze. Zaczyna się od podsumowania różnych alertów związanych z klastrem:
Następna sekcja dotyczy stanu węzłów, które są częścią klastra:
Masz listę węzłów w klastrze, ich typ, rolę (master lub slave), status węzła, czas pracy i system operacyjny.
Kolejną sekcją raportu jest podsumowanie kopii zapasowej, takie jak omówione powyżej. Kolejna przedstawia zestawienie najpopularniejszych zapytań w klastrze:
Na koniec widzimy „Przegląd stanu węzła”, w którym zostaną przedstawione wykresy związane ze wskaźnikami systemu operacyjnego i MySQL dla każdego węzła.
Jak widać, mamy tutaj wykresy obejmujące wszystkie aspekty obciążenia hosta - procesor, pamięć, sieć, dysk, obciążenie procesora i dysk wolny. To wystarczy, aby zorientować się, czy ostatnio wydarzyło się coś dziwnego, czy nie. Możesz również zobaczyć kilka szczegółów na temat obciążenia MySQL - ile zapytań zostało wykonanych, jaki typ zapytania, jak uzyskano dostęp do danych (przez który handler)? To z drugiej strony powinno wystarczyć do rozwiązania większości problemów po stronie MySQL. To, na co chcesz spojrzeć, to wszystkie skoki i spadki, których nie widziałeś w przeszłości. Być może do zestawu dodano nowe zapytanie, w wyniku czego handler_read_rnd_next wystrzelił w górę? Być może nastąpił wzrost obciążenia procesora, a duża liczba połączeń może wskazywać na zwiększone obciążenie MySQL, ale także na pewien rodzaj rywalizacji. Warto zbadać nieoczekiwany wzór, aby wiedzieć, co się dzieje.
Raport dotyczący aktualizacji pakietu
Ten raport zawiera podsumowanie pakietów dostępnych do aktualizacji przez menedżera repozytorium na monitorowanych hostach. Aby zapewnić dokładne raportowanie, upewnij się, że zawsze korzystasz ze stabilnych i zaufanych repozytoriów na każdym hoście. W niektórych niepożądanych przypadkach monitorowane hosty mogą być skonfigurowane z nieaktualnym repozytorium po aktualizacji (np. każda główna wersja MariaDB używa innego repozytorium), niekompletnym repozytorium wewnętrznym (np. częściowe zdublowane z pierwotnego repozytorium) lub repozytorium z krwawieniem (zwykle w przypadku niestabilnej pakiety do budowania w nocy).
Pierwsza sekcja to podsumowanie aktualizacji:
Podsumowuje całkowitą liczbę pakietów dostępnych do uaktualnienia, a także powiązane usługi zarządzane dla klastra, takie jak system równoważenia obciążenia, wirtualny adres IP i arbiter. Następnie ClusterControl zapewnia szczegółową listę pakietów, pogrupowaną według typu pakietu dla każdego hosta:
Ten raport zawiera dostępną wersję i może znacznie pomóc nam w efektywnym planowaniu naszego okna konserwacji. W przypadku aktualizacji krytycznych, takich jak pakiety bezpieczeństwa i bazy danych, możemy nadać im priorytet w stosunku do aktualizacji niekrytycznych, które można skonsolidować z innymi mniej priorytetowymi oknami konserwacyjnymi.
Raport o zmianie schematu
Ten raport porównuje wybrane zmiany bazy danych MySQL/MariaDB w strukturze tabeli, które zaszły między dwoma różnymi wygenerowanymi raportami. W starszych wersjach MySQL/MariaDB operacja DDL jest operacją nieatomową (przed 8.0) i wymaga pełnej kopii tabeli (przed 5.6 dla większości operacji) - blokując inne transakcje aż do jej zakończenia. Zmiany schematu mogą stać się ogromnym problemem, gdy Twoje tabele otrzymają znaczną ilość danych i muszą być starannie zaplanowane, zwłaszcza w konfiguracji klastrowej. W wielopoziomowym środowisku programistycznym widzieliśmy wiele przypadków, w których programiści po cichu modyfikują strukturę tabeli, co ma znaczący wpływ na wydajność zapytań.
Aby ClusterControl mógł wygenerować dokładny raport, należy skonfigurować specjalne opcje w pliku konfiguracyjnym CMON dla odpowiedniego klastra:
- schema_change_detection_address — Kontrole zostaną wykonane przy użyciu polecenia SHOW TABLES/SHOW CREATE TABLE w celu określenia, czy schemat uległ zmianie. Kontrole są wykonywane na podanym adresie i mają format NAZWA HOSTA:PORT. schema_change_detection_bazy danych musi być również ustawiony. Jest tworzona dyferencjał zmienionej tabeli (za pomocą diff).
- schema_change_detection_databases - Oddzielona przecinkami lista baz danych do monitorowania zmian w schemacie. Jeśli jest pusty, nie są wykonywane żadne kontrole.
W tym przykładzie chcielibyśmy monitorować zmiany schematu bazy danych „myapp” i „sbtest” w naszym klastrze MariaDB z identyfikatorem klastra 27. Wybierz jeden z węzłów bazy danych jako wartość schema_change_detection_address . W przypadku replikacji MySQL powinien to być host główny lub dowolny host podrzędny, który przechowuje bazy danych (w przypadku aktywnej replikacji częściowej). Następnie w /etc/cmon.d/cmon_27.cnf dodaj dwa następujące wiersze:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestUruchom ponownie usługę CMON, aby załadować zmianę:
$ systemctl restart cmonW przypadku pierwszego i najważniejszego raportu ClusterControl zwraca tylko wynik gromadzenia metadanych, podobnie jak poniżej:
Z pierwszym raportem jako punktem odniesienia, kolejne raporty zwrócą dane wyjściowe, których oczekujemy:
Zwróć uwagę, że w raporcie drukowane są tylko nowe lub zmienione tabele. Pierwszy raport służy tylko do zbierania metadanych do porównania w kolejnych rundach, dlatego musimy uruchomić go co najmniej dwa razy, aby zobaczyć różnicę.
Dzięki temu raportowi możesz teraz zebrać ślady struktury bazy danych i zrozumieć, jak Twoja baza danych ewoluowała w czasie.
Ostateczne myśli
Raport operacyjny to kompleksowy sposób na zrozumienie stanu infrastruktury bazy danych. Jest przeznaczony zarówno dla personelu operacyjnego, jak i kierowniczego i może być bardzo przydatny w analizie operacji na bazie danych. Raporty można generować na miejscu lub można je dostarczać pocztą elektroniczną, co ułatwia pracę, jeśli masz silos raportowania.
Chętnie poznamy Twoją opinię na temat wszystkiego, co chciałbyś uwzględnić w raporcie, czego brakuje, a co nie jest potrzebne.
