MySQL Server generuje kilka dzienników, które mogą pomóc w monitorowaniu aktywności serwera. Jednak po włączeniu tych dzienników mogą one wzrosnąć i zacząć zajmować zbyt dużo miejsca na dysku. Dlatego tak ważne jest posiadanie zautomatyzowanego sposobu archiwizowania i przechowywania plików logów MySQL przez określony czas, a także usuwania starych. W tym poście na blogu opisujemy kilka najlepszych praktyk dotyczących konfigurowania i zarządzania dziennikami błędów MySQL, dziennikami ogólnymi i dziennikami powolnych zapytań dla wdrożeń MySQL.
Konfigurowanie logowania do serwera MySQL
Przyjrzyjmy się, jak skonfigurować następujące 3 typy dzienników:
Dziennik błędów
Zapisuje wszystkie problemy napotkane podczas uruchamiania, uruchamiania lub zatrzymywania mysqld. Ten dziennik można włączyć, wybierając następującą opcję w pliku /etc/my.cnf:
- log_error=/var/log/mysql/mysqld.log
Ogólny dziennik zapytań
Zapisuje nawiązane połączenia klientów i wyciągi otrzymane od klientów. Ten dziennik można włączyć, wybierając następującą opcję w pliku /etc/my.cnf:
- general_log=WŁ
- general_log_file=/var/log/mysql/general.log
Dziennik powolnych zapytań
Zapisuje zapytania, których wykonanie zajęło więcej niż long_query_time sekund. Ten dziennik można włączyć za pomocą następującej opcji w pliku /etc/my.cnf:
- slow_query_log=WŁ
- slow_query_log_file=/var/log/mysql/mysql-slowquery.log
Konfigurowanie kryteriów rotacji dziennika
Jako przykład, przyjrzyjmy się kilku kryteriom zarządzania ogólnymi dziennikami zapytań MySQL. Możemy wymyślić odpowiedni zestaw kryteriów do zarządzania logami, zadając następujące pytania:
P:Jaki jest maksymalny rozmiar pliku dziennika?
O:Powiedzmy, że może wzrosnąć do 300 MB, po czym musi zostać obrócony i skompresowany.
P:Jaka jest częstotliwość rotacji pliku dziennika?
O:Możemy powiedzieć, że chcemy, aby logi były codziennie zmieniane.
P:Ile starych plików dziennika chcesz zachować?
O:Chcielibyśmy zachować ostatnie 30 plików dziennika.
W oparciu o powyższe kryteria ogólne miejsce na dysku wymagane do ogólnego zarządzania dziennikiem zapytań wynosi około 1,2 GB. Zakładając współczynnik kompresji 90% – będziemy mieć 30 skompresowanych plików dziennika o rozmiarze 30 MB każdy i plik dziennika na żywo o wielkości około 300 MB.
Zarządzanie dziennikami serwera MySQL:obracanie, kompresowanie, przechowywanie i usuwanieKliknij, aby tweetować
Zarządzanie dziennikami za pomocą narzędzia Linux logrotate
logrotate to narzędzie dla systemu Linux, które pomaga w wydajnym administrowaniu plikami dziennika i zapewnia opcje automatycznego obracania, kompresji i usuwania plików dziennika. Ustalone powyżej kryteria można skonfigurować dla narzędzia logrotate, tworząc plik konfiguracyjny w folderze /etc/logrotate.d.
Nazwijmy ten plik konfiguracyjny mysqlgeneral, a zawartość pliku będzie wyglądać następująco:
/var/log/mysql/general.log{
compress
dateext
maxsize 300M
copytruncate
maxage 365
dateformat -%Y%m%d%s
daily
rotate 30
notifempty
}
Dzięki powyższym opcjom logrotate, ogólne dzienniki zapytań są obracane codziennie lub gdy rozmiar pliku dziennika przekracza 300 MB. Stare logi są kompresowane i 30 takich plików zostanie zachowanych. Rotacja dziennika zostanie pominięta, jeśli plik dziennika jest pusty z powodu ustawienia „notifempty”.
Opcja „copytruncate” ma zapewnić, że bieżący plik dziennika nigdy nie zostanie usunięty podczas rotacji, a tylko jego zawartość zostanie obcięta. Jest to ważne, ponieważ niektóre aplikacje oczekują, że plik dziennika jest zawsze dostępny i nie można usunąć dziennika bez uprzedniego zatrzymania aplikacji.
Teraz, gdy konfiguracja rotacji dziennika jest ustawiona dla ogólnego dziennika zapytań, narzędzie logrotate musi zostać uruchomione, aby powyższa konfiguracja została wykonana. Odbywa się to zwykle za pomocą zadania cron. Możemy ustawić to tak, aby działał co godzinę, umieszczając skrypt logrotate w katalogu /etc/cron.hourly:
#!/bin/sh
/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
/usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0
Tak więc w kilku prostych krokach ustawiliśmy rotację logów dla ogólnych logów MySQL w oparciu o nasze kryteria. To samo podejście można zastosować również w przypadku dzienników błędów MySQL i dzienników powolnych zapytań. Sprawdź te inne posty, aby dowiedzieć się więcej o optymalizacji wdrożeń MySQL:
- Obliczanie rozmiaru puli buforów InnoDB dla twojego serwera MySQL
- Samouczek MySQL – konfiguracja i zarządzanie SSL na serwerze MySQL
- Wyjaśnienie struktury MySQL High Availability Framework — część I:Wprowadzenie