Przerwa w działaniu MySQL oznacza po prostu, że Twoja usługa MySQL jest niedostępna lub nie odpowiada z perspektywy drugiej strony. Przestoje mogą być spowodowane wieloma możliwymi przyczynami.
- Problem z siecią — problem z łącznością, przełącznik, routing, przelicznik, warstwa równoważenia obciążenia.
- Problem z zasobami — czy osiągnąłeś limit zasobów czy wąskie gardło.
- Błędna konfiguracja — Złe uprawnienia lub własność, nieznana zmienna, złe hasło, zmiana uprawnień.
- Blokowanie - Globalna blokada lub blokada tabeli uniemożliwia innym dostęp do danych.
W tym poście na blogu przyjrzymy się kilku krokom, które należy podjąć w przypadku awarii MySQL (środowisko Linux).
Krok pierwszy:pobierz kod błędu
Gdy wystąpi awaria, aplikacja wyrzuci pewne błędy i wyjątki. Błędy te często zawierają kod błędu, który daje przybliżony obraz tego, z czym masz do czynienia i co zrobić, aby rozwiązać problem i odzyskać awarię.
Aby uzyskać więcej informacji na temat błędu, sprawdź odpowiednio strony Kod błędu MySQL lub Kod błędu MariaDB, aby dowiedzieć się, co oznacza błąd.
Krok drugi:Czy serwer MySQL działa?
Zaloguj się do serwera przez terminal i sprawdź, czy demon MySQL działa i nasłuchuje na poprawnym porcie. W Linuksie można wykonać następujące czynności:
Najpierw sprawdź proces MySQL:
$ ps -ef | grep -i mysqlPowinieneś dostać coś w zamian. W przeciwnym razie MySQL nie działa. Jeśli MySQL nie działa, spróbuj go uruchomić:
$ systemctl start mysql # systemd
$ service mysql start # sysvinit/upstart
$ mysqld_safe # manualJeśli widzisz błąd w powyższym kroku, powinieneś zajrzeć do dziennika błędów MySQL, który różni się w zależności od systemu operacyjnego i konfiguracji zmiennych MySQL dla log_error w pliku konfiguracyjnym MySQL. W przypadku serwera opartego na RedHat plik zwykle znajduje się pod adresem:
$ cat /var/log/mysqld.logZwróć uwagę na najnowsze wiersze z poziomem dziennika „[Błąd]”. Niektóre wiersze oznaczone „[Ostrzeżenie]” mogą wskazywać na pewne problemy, ale są one dość rzadkie. W większości przypadków błędną konfigurację i problemy z zasobami można wykryć tutaj.
Jeśli MySQL działa, sprawdź, czy nasłuchuje na właściwym porcie:
$ netstat -tulpn | grep -i mysql
tcp6 0 0 :::3306 :::* LISTEN 1089/mysqldOtrzymasz nazwę procesu "mysqld", nasłuchującego na wszystkich interfejsach (:::3306 lub 0.0.0.0:3306) na porcie 3306 z PID 1089 i stanem "LISTEN". Jeśli widzisz powyższy wiersz pokazuje 127.0.0.1:3306, MySQL nasłuchuje tylko lokalnie. Być może będziesz musiał zmienić wartość bind_address w pliku konfiguracyjnym MySQL, aby nasłuchiwać wszystkich adresów IP, lub po prostu skomentować wiersz.
Krok trzeci:Sprawdź problemy z łącznością
Jeśli serwer MySQL działa poprawnie bez błędów w dzienniku błędów MySQL, prawdopodobieństwo wystąpienia problemów z łącznością jest dość wysokie. Zacznij od sprawdzenia łączności z hostem przez ping (jeśli włączony jest ICMP) i telnet z serwerem MySQL z serwera aplikacji:
(application-server)$ ping db1.mydomain.com
(application-server)$ telnet db1.mydomain.com 3306
Trying db1.mydomain.com...
Connected to 192.168.0.16.
Escape character is '^]'.
O
5.6.46-86.2sN&nz9NZ�32?&>H,EV`_;mysql_native_passwordPowinieneś zobaczyć kilka linii na wyjściu telnetu, jeśli możesz połączyć się z portem MySQL. Teraz spróbuj jeszcze raz, używając klienta MySQL z serwera aplikacji:
(application-server)$ mysql -u db_user -p -h db1.mydomain.com -P3306
ERROR 1045 (28000): Access denied for user 'db_user'@'db1.mydomain.com' (using password: YES)W powyższym przykładzie błąd daje nam trochę informacji o tym, co robić dalej. Powyższe prawdopodobnie dlatego, że ktoś zmienił hasło dla "db_user" lub hasło dla tego użytkownika wygasło. Jest to raczej normalne zachowanie z MySQL 5.7. 4 i wyżej, gdzie polityka automatycznego wygasania haseł jest domyślnie włączona z progiem 360 dni - co oznacza, że wszystkie hasła wygasają raz w roku.
Krok czwarty:Sprawdź listę procesów MySQL
Jeśli MySQL działa poprawnie bez problemów z łącznością, sprawdź listę procesów MySQL, aby zobaczyć, jakie procesy są aktualnie uruchomione:
mysql> SHOW FULL PROCESSLIST;
+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+
| Id | User | Host | db | Command | Time | State | Info | Rows_sent | Rows_examined |
+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+
| 117 | root | localhost | NULL | Query | 0 | init | SHOW FULL PROCESSLIST | 0 | 0 |
+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+
1 row in set (0.01 sec)Zwróć uwagę na kolumnę Informacje i czas. Niektóre operacje MySQL mogą być na tyle destrukcyjne, że baza danych zatrzymuje się i przestaje odpowiadać. Następujące instrukcje SQL, jeśli są uruchomione, mogą zablokować innym dostęp do bazy danych lub tabeli (co może spowodować krótką awarię usługi MySQL z perspektywy aplikacji):
- STOŁY DO PŁUKANIA Z BLOKADĄ ODCZYTU
- ZABLOKUJ TABELĘ ...
- ZMIEŃ TABELĘ ...
Niektóre długotrwałe transakcje mogą również opóźnić działanie innych, co ostatecznie spowoduje przekroczenie limitu czasu dla innych transakcji oczekujących na dostęp do tych samych zasobów. Możesz albo zabić obraźliwą transakcję, aby umożliwić innym dostęp do tych samych wierszy, albo ponowić transakcję w kolejce po zakończeniu długiej transakcji.
Wnioski
Proaktywne monitorowanie jest bardzo ważne, aby zminimalizować ryzyko awarii MySQL. Jeśli Twoja baza danych jest zarządzana przez ClusterControl, wszystkie wymienione aspekty są monitorowane automatycznie bez dodatkowej konfiguracji ze strony użytkownika. Będziesz otrzymywać alarmy w swojej skrzynce odbiorczej dotyczące wykrycia anomalii, takich jak długotrwałe zapytania, błędna konfiguracja serwera, przekroczenie progu zasobów i wiele innych. Ponadto ClusterControl automatycznie spróbuje odzyskać usługę bazy danych, jeśli coś pójdzie nie tak z hostem lub siecią.
Możesz również dowiedzieć się więcej o MySQL i MariaDB Disaster Recovery, czytając naszą białą księgę.
