Wydawałoby się, że sprawa jest oczywista, ale biorąc pod uwagę ilość pytań z Google dotyczących tego tematu, wygląda na to że nie jest tak do końca. Tak więc dziś szukamy logów MySQL. Jakie są te logi i do czego służą?

MySQL posiada kilka rodzajów logów:

error log – log, do którego logowane są informacje na temat startu i zatrzymania się serwera MySQL, a także wszelkie informacje dotyczące krytycznych błędów, które wystąpiły w trakcie działania serwera. W szczególności logowane są tu informacje o tym, które tabele są uszkodzone i powinny zostać naprawione, a także zrzut stosu, przydatny do debugowania problemów z segfaultami. Jeśli włączona jest opcja automatycznej naprawy tabel MyISAM, to także w tym logu znajdą się informacje o przebiegu tego procesu.

general log – log, który obejmuje informacje na temat bieżącej pracy MySQL. Logowane są w nim informacje o połączeniach – jaki użytkownik, z jakiego hosta, czy się poprawnie autoryzował. Trafiają tu także informacje o wszystkich zapytaniach jakie zostały wysłane do serwera MySQL. Ze względu na dużą ilość danych zapisywanych w tym logu, co negatywnie wpływa na wydajność serwera, domyślnie jest on wyłączony.

binary log – log ten to postać binarna wszelkich zmian, jakie zostały wprowadzone w bazach danego serwera MySQL. Dzięki binlogowi możliwe jest odtworzenie zawartości bazy w dowolnym punkcie czasu – wystarczy że posiadamy kopię zapasową danych np. na godzinę 00:00 a także binlogi od tego momentu do chwili obecnej. Binlog jest też podstawą działania replikacji MySQL. Więcej na temat replikacji można znaleźć w poprzednich postach.

relay log – jest to binlog przegrany z serwera master na serwer slave, wykorzystywany przez slave do odtworzenia modyfikacji danych wykonanych na serwerze master – log ten występuje tylko gdy skonfigurowana jest replikacja.

slow query log – log do którego trafiają wszelkie zapytania, których czas wykonania przekroczył ustawiony w konfiguracji czas. Czas ten zdefiniowany jest w zmiennej long_query_time. Dane z tego logu ułatwiają wykonanie analizy obciążenia serwera MySQL. Więcej informacji na temat tego loga można znaleźć w moich wcześniejszych postach – Logi MySQL – slowlog i Rozszerzony slowlog .

Ok, wiemy już z jakimi logami mamy do czynienia. Gdzie one w takim razie są? No cóż, to zależy od konfiguracji serwera. Najprościej jest zalogować się do konsoli MySQL i sprawdzić samemu.

error log –  tu sprawa jest o tyle skomplikowana, że część dystrybucji Linuksa (na przykład Debian) zdecydowało się przerobić MySQL tak, że zawartość tego logu trafia do sysloga i tam znajduje się konfiguracja dotycząca tego, gdzie te logi lądują. Jeśli log ten jest obsługiwany przez MySQL, to jego lokalizację ujawni zapytanie

SHOW GLOBAL VARIABLES LIKE 'log_error';

Domyślną lokalizacją jest plik nazwahosta.err w katalogu z bazami danych, czyli

SHOW GLOBAL VARIABLES LIKE 'datadir';

general log – konfiguracja zależy od wersji MySQL. Dokładne informacje znaleźć można w dokumentacji, na przestrzeni rozwoju MySQL 5.1 trochę się to zmieniało. Co jest istotne, to to że w przypadku MySQL 5.0 i starszych lokalizację wskazuje zmienna ‚log’ (do sprawdzenia w pliku my.cnf), natomiast od  MySQL 5.1.29 począwszy, czyli w praktycznie każdej nowej bazie danych, zmienna ‚general_log’ decyduje czy log ten jest włączony, a zmienna ‚general_log_file’ decyduje o lokalizacji. Sprawdzić to możemy poleceniem:

SHOW GLOBAL VARIABLES LIKE 'general_log%';

Domyślnie przyjmuje on nazwę nazwahosta.log i tworzony jest w ‚datadir’. Jeśli włączone jest logowanie do tabel (taka opcja pojawia się w MySQL 5.1), zawartość tego logu trafiać będzie do tabeli `general_log` w bazie `mysql`.

binary log – za lokalizację odpowiada zmienna w my.cnf o nazwie log-bin. Niestety, nie widać tego z poziomu konsoli – zmienna ‚log_bin’ wskazuje tylko czy binlogi są włączone. Trzeba po prostu sprawdzić zawartość pliku konfiguracyjnego. Domyślnie binlogi tworzone są w ‚datadir’.

relay log – lokalizację można sprawdzić z poziomu konsoli MySQL przy pomocy polecenia:

SHOW GLOBAL VARIABLES LIKE 'relay_log';

Domyślnie są tworzone w ‚datadir’.

slow query log – tu, podobnie jak w przypadku general log, sposów konfiguracji zmieniał się w czasie. Dokładne informacje można znaleźć w dokumentacji. W przypadku MySQL 5.0 lokalizację definiuje zmienna ‚log_slow_queries’, informację o lokalizacji możemy też uzyskać z poziomu konsoli serwera i robi się to tak, jak w przypadku MySQL 5.1. Od MySQL 5.1.29 począwszy konfiguracja slowlogów odbywa się już tylko przez zmienne globalne a więc to, czy slowlogi są włączone i gdzie trafiają sprawdzimy w następujący sposób:

SHOW GLOBAL VARIABLES LIKE 'slow_query_log%';

Jeśli włączone jest logowanie do tabel, slowlogi trafiają do tabelu `slow_log` w bazie `mysql`.

Mam nadzieję, że powyższe informacje wystarczą każdemu administratorowi MySQL, który chce znaleźć logi na serwerze, którego konfiguracji nie zna.