Zaraz po uruchomieniu serwera bazy danych i wzroście użycia, jesteś narażony na wiele rodzajów problemów technicznych, pogorszenie wydajności i awarie bazy danych. Każdy z nich może prowadzić do znacznie większych problemów, takich jak katastrofalna awaria lub utrata danych. To jak reakcja łańcuchowa, w której jedna rzecz może prowadzić do drugiej, powodując coraz więcej problemów. Aby zapewnić stabilne środowisko tak długo, jak to możliwe, należy zastosować proaktywne środki zaradcze.
W tym poście na blogu przyjrzymy się kilku fajnym funkcjom oferowanym przez ClusterControl, które mogą nam bardzo pomóc w rozwiązywaniu problemów z bazą danych MySQL, gdy się pojawią.
Alarmy i powiadomienia bazy danych
W przypadku wszystkich niepożądanych zdarzeń, ClusterControl zapisze wszystko w Alarmach, dostępnym na stronie Aktywność (Górne menu) strony ClusterControl. Jest to zwykle pierwszy krok do rozpoczęcia rozwiązywania problemów, gdy coś pójdzie nie tak. Na tej stronie możemy uzyskać wyobrażenie o tym, co faktycznie dzieje się z naszym klastrem baz danych:
Powyższy zrzut ekranu przedstawia przykład zdarzenia nieosiągalnego serwera o wadze KRYTYCZNE , wykrywany przez dwa komponenty, sieć i węzeł. Jeśli skonfigurowałeś ustawienia powiadomień e-mail, powinieneś otrzymać kopię tych alarmów w swojej skrzynce pocztowej.
Klikając „Pełne szczegóły alarmu”, możesz uzyskać ważne szczegóły alarmu, takie jak nazwa hosta, znacznik czasu, nazwa klastra i tak dalej. Zawiera również kolejny zalecany krok do wykonania. Możesz również wysłać ten alarm jako wiadomość e-mail do innych odbiorców skonfigurowanych w Ustawieniach powiadomień e-mail.
Możesz także uciszyć alarm, klikając przycisk „Ignoruj alarm”, a alarm nie pojawi się ponownie na liście. Zignorowanie alarmu może być przydatne, jeśli masz alarm o niskim poziomie ważności i wiesz, jak sobie z nim radzić lub go obejść. Na przykład, jeśli ClusterControl wykryje zduplikowany indeks w Twojej bazie danych, który w niektórych przypadkach byłby potrzebny starszym aplikacjom.
Przeglądając tę stronę, możemy uzyskać natychmiastowe zrozumienie, co dzieje się z naszym klastrem baz danych i co należy zrobić, aby rozwiązać problem. Podobnie jak w tym przypadku, jeden z węzłów bazy danych uległ awarii i stał się nieosiągalny przez SSH z hosta ClusterControl. Nawet początkujący administrator SysAdmin wiedziałby teraz, co dalej, jeśli pojawi się ten alarm.
Scentralizowane pliki dziennika bazy danych
W tym miejscu możemy zbadać, co było nie tak z naszym serwerem bazy danych. W ClusterControl -> Logs -> System Logs można zobaczyć wszystkie pliki dziennika związane z klastrem bazy danych. Jeśli chodzi o klaster baz danych oparty na MySQL, ClusterControl pobiera dziennik ProxySQL, dziennik błędów MySQL i dzienniki kopii zapasowych:
Kliknij „Odśwież dziennik”, aby pobrać najnowszy dziennik ze wszystkich hostów, które są dostępne w danym czasie. Jeśli węzeł jest nieosiągalny, ClusterControl nadal będzie wyświetlać nieaktualne dane logowania, ponieważ informacje te są przechowywane w bazie danych CMON. Domyślnie ClusterControl pobiera dzienniki systemowe co 10 minut, konfigurowalne w Ustawieniach -> Interwał dziennika.
ClusterControl uruchomi zadanie, aby pobrać najnowszy dziennik z każdego serwera, jak pokazano w następującym zadaniu „Zbieranie dzienników”:
Scentralizowany widok pliku dziennika pozwala nam szybciej zrozumieć, co się stało zło. W przypadku klastra bazy danych, który często obejmuje wiele węzłów i warstw, ta funkcja znacznie poprawi odczyt dzienników, w których administrator SysAdmin może porównać te dzienniki obok siebie i wskazać krytyczne zdarzenia, skracając całkowity czas rozwiązywania problemów.
Konsola Web SSH
ClusterControl zapewnia internetową konsolę SSH, dzięki czemu można uzyskać dostęp do serwera DB bezpośrednio za pośrednictwem interfejsu użytkownika ClusterControl (ponieważ użytkownik SSH jest skonfigurowany do łączenia się z hostami bazy danych). Stąd możemy zebrać znacznie więcej informacji, co pozwoli nam jeszcze szybciej rozwiązać problem. Każdy wie, kiedy problem z bazą danych trafia do systemu produkcyjnego, liczy się każda sekunda przestoju.
Aby uzyskać dostęp do konsoli SSH przez Internet, po prostu wybierz węzły w sekcji Węzły -> Akcje węzłów -> Konsola SSH lub po prostu kliknij ikonę koła zębatego, aby uzyskać skrót:
Ze względu na obawy związane z bezpieczeństwem, które mogą zostać nałożone za pomocą tej funkcji, szczególnie w przypadku -środowisko user lub multi-tenant, można je wyłączyć przechodząc do /var/www/html/clustercontrol/bootstrap.php na serwerze ClusterControl i ustawić następującą stałą na false:
define('SSH_ENABLED', false);Odśwież stronę ClusterControl UI, aby załadować nowe zmiany.
Problemy z wydajnością bazy danych
Oprócz funkcji monitorowania i trendów, ClusterControl proaktywnie wysyła różne alarmy i porady związane z wydajnością bazy danych, na przykład:
- Nadmierne użycie — zasób, który przekracza określone progi, takie jak procesor, pamięć, użycie wymiany i miejsce na dysku.
- Pogorszenie jakości klastra — partycjonowanie klastra i sieci.
- Dyf czasu systemowego — różnica czasu między wszystkimi węzłami w klastrze (w tym węzłem ClusterControl).
- Różni inni doradcy powiązani z MySQL:
- Replikacja — opóźnienie replikacji, wygaśnięcie binlogu, lokalizacja i wzrost
- Galera - metoda SST, skanowanie dziennika GRA, sprawdzanie adresu klastra
- Sprawdzenie schematu – istnienie tabeli nietransakcyjnej w klastrze Galera.
- Połączenia - stosunek wątków połączonych
- InnoDB - Współczynnik brudnych stron, wzrost pliku dziennika InnoDB
- Powolne zapytania — domyślnie ClusterControl podniesie alarm, jeśli znajdzie zapytanie działające dłużej niż 30 sekund. Można to oczywiście skonfigurować w Ustawienia -> Konfiguracja środowiska wykonawczego -> Długie zapytanie.
- Zakleszczenia — zakleszczenie transakcji InnoDB i zakleszczenie w Galera.
- Indeksy — zduplikowane klucze, tabela bez kluczy podstawowych.
Sprawdź stronę Doradcy w sekcji Wydajność -> Doradcy, aby uzyskać szczegółowe informacje na temat rzeczy, które można ulepszyć zgodnie z sugestiami ClusterControl. Dla każdego doradcy zawiera uzasadnienia i porady, jak pokazano w poniższym przykładzie dla doradcy „Sprawdzanie wykorzystania miejsca na dysku”:
Gdy wystąpi problem z wydajnością, pojawi się „Ostrzeżenie” (żółte) lub Status „krytyczny” (czerwony) tych doradców. Aby rozwiązać ten problem, zwykle wymagane jest dalsze dostrajanie. Doradcy zgłaszają alarmy, co oznacza, że użytkownicy otrzymają kopię tych alarmów w skrzynce pocztowej, jeśli powiadomienia e-mail są odpowiednio skonfigurowane. W przypadku każdego alarmu zgłoszonego przez ClusterControl lub jego doradców, użytkownicy otrzymają również wiadomość e-mail, jeśli alarm został skasowany. Są one wstępnie skonfigurowane w ClusterControl i nie wymagają wstępnej konfiguracji. Dalsze dostosowywanie jest zawsze możliwe w Zarządzaj -> Developer Studio. Możesz sprawdzić ten post na blogu, aby dowiedzieć się, jak napisać własnego doradcę.
ClusterControl udostępnia również dedykowaną stronę dotyczącą wydajności bazy danych w ClusterControl -> Performance. Zapewnia wszelkiego rodzaju wgląd w bazy danych zgodnie z najlepszymi praktykami, takimi jak scentralizowany widok stanu bazy danych, zmiennych, stanu InnoDB, analizatora schematu, dzienników transakcji. Są one dość oczywiste i łatwe do zrozumienia.
W celu sprawdzenia wydajności zapytań można sprawdzić najpopularniejsze zapytania i wartości odstające zapytań, gdzie ClusterControl wyróżnia zapytania, których wykonanie znacznie różni się od ich przeciętnego zapytania. Szczegółowo omówiliśmy ten temat w tym poście na blogu, Dostrajanie wydajności zapytań MySQL.
Raporty o błędach bazy danych
ClusterControl jest wyposażony w narzędzie do generowania raportów o błędach, które zbiera informacje debugowania dotyczące klastra bazy danych, aby pomóc w zrozumieniu bieżącej sytuacji i stanu. Aby wygenerować raport o błędach, po prostu przejdź do ClusterControl -> Dzienniki -> Raporty o błędach -> Utwórz raport o błędach:
Wygenerowany raport o błędach można pobrać z tej strony, gdy będzie gotowy. Ten wygenerowany raport będzie w formacie kuli TAR (tar.gz) i możesz go dołączyć do zgłoszenia serwisowego. Ponieważ zgłoszenie do pomocy technicznej ma limit 10 MB rozmiaru pliku, jeśli rozmiar pliku tar jest większy niż ten, możesz przesłać go na dysk w chmurze i udostępnić nam link do pobrania tylko z odpowiednimi uprawnieniami. Możesz go usunąć później, gdy już otrzymamy plik. Raport o błędach można również wygenerować za pomocą wiersza poleceń, jak wyjaśniono na stronie dokumentacji Raportu o błędach.
W przypadku awarii zdecydowanie zalecamy generowanie wielu raportów o błędach w trakcie i zaraz po awarii. Raporty te będą bardzo przydatne, aby spróbować zrozumieć, co poszło nie tak, konsekwencje awarii i zweryfikować, czy klaster faktycznie powrócił do stanu operacyjnego po katastrofalnym zdarzeniu.
Wnioski
Proaktywne monitorowanie ClusterControl wraz z zestawem funkcji rozwiązywania problemów zapewnia wydajną platformę dla użytkowników do rozwiązywania wszelkiego rodzaju problemów z bazą danych MySQL. Dawno już minął stary sposób rozwiązywania problemów, w którym trzeba otworzyć wiele sesji SSH, aby uzyskać dostęp do wielu hostów i wielokrotnie wykonywać wiele poleceń, aby wskazać główną przyczynę.
Jeśli wyżej wymienione funkcje nie pomagają w rozwiązaniu problemu lub rozwiązaniu problemu z bazą danych, zawsze skontaktuj się z zespołem pomocy technicznej Manynines, aby uzyskać kopię zapasową. Nasi oddani eksperci techniczni 24/7/365 są dostępni w każdej chwili, aby odpowiedzieć na Twoje żądanie. Nasz średni czas pierwszej odpowiedzi to zwykle mniej niż 30 minut.
