LNMP – Część 4: MariaDB

Ponad półtora miesiąca temu napisałem poprzednią część tej serii… Oj strasznie, strasznie długa przerwa. Pozostaje mi was przeprosić, bo ten kto czekał mógł już stwierdzić, że się nie doczeka no i uznał, że nie kończę tego co zacząłem. Cóż poradzić… dopadł mnie całkowity marazm, było bardzo źle, nadal jest źle… ale to chyba sprawa na zupełnie inną dyskusję, nie dotyczy ona przecież dzisiejszego tematu, a więc dalszej konfiguracji środowiska LNMP. Podsumujmy najpierw co już mamy – dodane repozytoria, mamy zainstalowanego nginxa, mamy też PHP-FPM. W efekcie możemy serwować zarówno treści statyczne jak i dynamiczne. Bez bazy to będzie jednak dosyć kulawa konfiguracja, dlatego czas na literkę „M” ze skrótu, dzisiaj zajmiemy się MariaDB.

Dlaczego właśnie MariaDB?

Na początek, gwoli wyjaśnienia, dlaczego tak w ogóle MariaDB a nie MySQL? Przede wszystkim chodzi tutaj o niezależność. MySQL jest utrzymywane przez Oracle i w zasadzie nie wiadomo jak to się skończy dla tej bazy, prognozy nie są zbyt ciekawe. MariaDB nie jest zależna od jednej konkretnej firmy, ma otwarte źródła i coraz więcej projektów zaczyna z niej korzystać. Wystarczy wspomnieć chociażby o ostatniej informacji o tym, że Google swoje serwery bazodanowe przerzuca właśnie na MariaDB, co więcej, na wersję nie uznawaną jeszcze oficjalnie za stabilną i znajdującą się w fazie rozwojowej. W gruncie rzeczy, co wybierzecie leży w waszej gestii. Poradnik ten nie zahacza o żadne różnice między tymi bazami, równie dobrze sporo jego fragmentów może być zastosowanych przy konfiguracji MySQL. Wybór pozostawiam wam, zachęcam jednak do MariaDB – ja migrowałem na nią z MySQL i naprawdę nie żałuję, pomimo niewielkich baz jest szybciej niż było.

Zabieramy się do instalacji

To co będziemy musieli zrobić na początku, to dodanie odpowiednie repozytoria. Na oficjalnej stronie projektu znajdziemy bardzo wygodny kreator, pozwalający na wybranie używanej przez nas dystrybucji, następnie wersji, a ostatecznie również mirrora, abyśmy mogli korzystać z najbliższej lokalizacji. Ja dla przykładu wybrałem Debiana 7 Wheezy, bazę w wersji 10, a serwery znajdujące się w Kolonii. W efekcie otrzymałem dokładną instrukcję jak dodać repozytoria – najpierw instalacja odpowiedniego pakietu, później pobranie kluczy, a na koniec dodawanie repo przy pomocy add-apt-repository (domyślnie Debian tego nie posiada, po to był odpowiedni klucz):

aptitutde install python-software-properties 
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db 
add-apt-repository 'deb http://mirror.netcologne.de/mariadb/repo/10.0/debian wheezy main'

Następnie można przejść do instalacji. Najpierw będzie oczywiście konieczna aktualizacja repozytoriów:

aptitude update 
aptitude install mariadb-server

Wszystkie te polecenia wydajemy z uprawnieniami użytkownika root. Kreator na pewno stworzy reguły zawierające sudo, a także apt-get zamiast aptitude, ale w poprzednich odcinkach trzymałem się tej konwencji, więc niech tak pozostanie. W trakcie instalacji zostaniemy zapytani o hasło administratora bazy. Oczywiście nie powinno to być nic typu „domek” lub „qwerty”. Po instalacji baza od razu zostanie uruchomiona i będzie gotowa do pracy. Sprawdzić to możemy logując się:

mysql –uroot –p

Po podaniu hasła będziemy mogli wydawać polecenia w języku SQL. Zanim przejmdziemy do sprawdzenia konfiguracji, wróćmy na chwilę do PHP. Jeżeli do tej pory nie instalowaliśmy modułu odpowiedzialnego za połączenia z bazą, zróbmy to teraz przy pomocy polecenia:

aptitude install php5-mysql

Wielkiej filozofii nie ma, przejdźmy więc dalej.

Konfiguracja serwera bazodanowego

To co warto sprawdzić i dopasować do własnych potrzeb, to konfiguracja bazy. Znajdziemy ją w pliku /etc/my.cnf. Cały problem polega na tym, że każda system bazodanowy, każdy serwis wymaga tak naprawdę innej konfiguracji. To nie jest coś, co można ustawić dobrze raz, a potem kopiować na różne inne konfiguracje i z zadowoleniem patrzeć jak działa. Niestety, nie tędy droga. Baza wymaga nadzorowania i zmiany konfiguracji jeżeli zajdzie taka potrzeba. Dlatego tutaj chciałbym przedstawić tylko najważniejsze opcje, a nieco dalej podać przykład narzędzia, które może w pewien sposób pomóc w dalszej konserwacji i obserwacjach, gdy już uruchomimy serwis i będzie on działał. To co zobaczymy na początku pliku to poza informacjami zakomentowanym dane o porcie i używanym sockecie. Nie musimy tego ruszać, robimy to tylko gdy naprawdę wiemy po co i co chcemy tym osiągnąć. Część dalszych opcji pozostawiamy bez zmian, ważna jest natomiast linijka odpowiedzialna za to, na jakim interfejsie nasłuchuje baza:

bind-address    = 127.0.0.1

Domyślna konfiguracja pozwala na łączenie tylko lokalne. Najlepiej tak to zostawić jeżeli nie potrzebujemy możliwości łączenia z innych maszyn. Włączenie nasłuchu na innych adresach, np. IP naszego serwera pozwala na to, aby z bazą połączył się ktokolwiek, a to może mieć opłakane skutki jeżeli dojdzie do przechwycenia danych logowania. Nie musimy – nie zmieniamy. Dalej znajdziemy opcje, które już bezpośrednio dotyczą wydajności. Trudno cokolwiek na tym etapie zalecać, domyślnie konfiguracja przewiduje wcale nie taki mały ruch, pożera nieco zasobów, ale dzięki temu baza działa dosyć szybko. Jedyne co mogę w tym momencie zalecić, to zmniejszenie ilości maksymalnych połączeń. Domyślnie limit ten wynosi 100, co jest już całkiem sporą wartością jak na serwis umieszczony na VPSie (chodzi tu o jednoczesne połączenia). Zmieniamy na coś bardziej realnego, jeżeli zajdzie potrzeba, limit zwiększymy:

max_connections = 20

Dalsze opcje dotyczą MyISAM, a także buforowania zapytań, na początek zostawimy domyślne. Przechodzimy do sekcji dotyczącej logów. Mamy do dyspozycji 3 z nich. Domyślnie wyłączony główny system logowania zapisuje wszystko co dzieje się w bazie… zgodnie z tym co mówią same komentarze w tej sekcji, jest to swoisty „performance killer” – oprócz wykonywania samego zapytania, trzeba dodatkowo zapisać wszystkie informacje. Jego włączanie nie jest zalecane, robimy to tylko gdy zajdzie stosowna potrzeba. Dalej mamy coś bardziej użytecznego, a mianowicie slow log. Ten zapisuje informacje o zapytaniach, które wykonywały się zbyt długo. Co to oznacza? Chodzi o zapytania, które przekroczą ustalony przez nas czas. Wartą włączyć tę opcję, aby wiedzieć czy nasza witryna, nasze skrypty w jakims miejscu nie powodują swoistego „orania” bazy. Poniżej przedstawiam przykładowe ustawienie:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 3
# log-queries-not-using-indexes

Pierwsza linijka włącza slow log, druga wskazuje gdzie będzie zapisywany, a trzecia to limit w sekundach – każde zapytanie którego wykonanie potrwa dłużej niż 3 sekundy, zostanie odnotowane w tym logu. Ostatnia, zakomentowana, po odkomentowaniu spowoduje zapisywanie również tych zapytań, które nie wykorzsytują indeksów, nawet jeżeli ich czas będzie krótszy niż zakłada limit. Bywa to bardzo przydatne, pozostawiam więc w decyzji użytkownika. Ostatni z logów pozwala na replikację, a w wypadku awarii lub stosownej potrzeby, odtworzenie bazy z dowolnego momentu zawartego w logu – zapisuje zapytania, które modyfikują bazę. W efekcie jeżeli posiadamy kopię z określonej godziny, a następnie wykonamy wszystkie zapytania z logu od niej aż do jego końca lub wybranego czasu, otrzymamy bazę w takim stanie w jakim była w tamtym momencie. Domyślnie log_bin jest włączony. Jeżeli opcja ta nie jest nam potrzebna, możemy ją wyłączyć dla zwiększenia wydajności.

Ostatnia z sekcji dotyczy InnoDB – jest on domyślnym mechanizmem składowania danych, nic w tym zresztą dziwnego, bo jest on najbardziej rozwijany i posiada szereg zalet względem MyISAM. Domyślne ustawienia na początek wystarczą. Później, w szczególności ze wzrostem wielkości baz będzie konieczna ich zmiana, przede wszystkim wartości innodb_buffer_pool_size oraz innodb_log_buffer_size. Resztę ustawień zmieniamy albo wedle własnych potrzeb, albo zostawiamy na domyślnych ustawieniach.

MySQLTuner – powie Ci, co nie tak z Twoją bazą

Na koniec wspomniane przykładowe narzędzie, do badania stanu bazy. Jest ono automatyczne, nie wie tak naprawdę co przechowujemy, a więc nie jest doskonałe i trzeba to mieć na uwadze. Pozwala jednak na szybkie wyświetlenie najważniejszych informacji, poprawę najbardziej rażących błędów i znalezienie niektórych przyczyn na pytanie „dlaczego to tak bardzo wolno działa?”. Narzędzie to napisany w perlu MySQLTuner, dostępny w serwisie GitHub:

https://github.com/major/MySQLTuner-perl

Wystarczy go pobrać, a następnie uruchomić poleceniem perl mysqltuner.pl. Po podaniu hasła administratora otrzymamy wyniki analizy. Jak napiałem, nie są one jedyną informacją na jakiej powinniśmy bazować, ale dają pewien rzut na sprawę.

Podsumowanie

To już koniec dzisiejszego odcinka. Część ta była bardziej ogólna, bardziej opisowa. Zdaję sobie z tego sprawę, ale jak już napisałem, konkretne potrzeby wymagają konkretnych ustawień. Nie ma tu złotego środka, nie ma rozwiązania uniwersalnego. Baza musi być przez nas pilnowana, doglądana i konserwowana. Taki jej urok. Jeżeli o to nie zadbamy, na pewno miło się nam nie odwdzięczy. Czy będą dalsze odcinki? Najprawdopodobniej tak. W kolejnym przedstawię sposób instalacji i konfiguracji phpMyAdmina, skryptu, dzięki któremu będziemy mogli zarządzać bazą z poziomu interfejsu www.