Podstawowa konfiguracja silnika XtraDB:

Poprawianie wydajności niemal zawsze sprowadza się do trzech następujących elementów: sprzętu, systemu operacyjnego i konfiguracji bazy danych. Składowa sprzętowa jest zazwyczaj dość prosta; w przypadku baz danych ogólna reguła jest taka, że im szybszy dysk, procesor i więcej pamięci RAM, tym lepiej. System
operacyjny możemy przyśpieszać na wiele sposobów — mamy do dyspozycji opcje montowania dysku, ustawienia sysctl, zarządcę procesami jądra i wiele innych. Również bazy danych możemy konfigurować na wiele różnych sposobów, dostępne są także strategie optymalizacji bazodanowej. Skoncentrujemy się na podstawowej konfiguracji silnika XtraDB na serwerze MariaDB.

W jaki sposób silnik InnoDB przechowuje dane?:

Schemat przechowywania danych w silniku InnoDB (a zatem również XtraDB) jest dwupoziomowy. Dane zapisane na dysku znajdują się w katalogu /var/lib/mysql. W jego wnętrzu znajdziemy również pliki ibdata1, ib_logfile0 i ib_logfile1. Plik ibdata1 zawiera dane systemowe i użytkownika, pozostałe dwa natomiast stanowią dzienniki cofnięć (transakcji). Bazy danych są tworzone wewnątrz katalogów /var/lib/mysql/<nazwabazydanych>. Z kolei tabele tworzące te bazy danych są zapisywane w następującym miejscu: /var/lib/mysql/<nazwabazydanych>/<nazwatabeli>.frm. Gdy zawartość tabeli zostaje zmodyfikowana w pamięci komputera (np. z powodu wprowadzenia rekordu), silnik InnoDB zapisuje zmiany w dzienniku cofnięć. Po zapełnieniu miejsca w tych dziennikach przechowywane w nich informacje zostają przeniesione do plików tabel. Jednym z powodów takiego postępowania jest kwestia wydajności, przypominająca zresztą proces księgowania systemu plików. Przeprowadzając wszystkie te operacje jednocześnie, dysk zapisuje dane znacznie szybciej. Inną przyczyną jest trwałość, gdyż dzienniki cofnięć pozwalają na odtwarzanie transakcji po nieoczekiwanym przerwaniu działania systemu. W momencie wyłączania serwera MariaDB informacje w dziennikach transakcji nie są przetwarzane, zatem zazwyczaj przechowują one bieżące dane. Oznacza to, że nie można ich usuwać ani odtwarzać w celu zwiększenia lub zmniejszenia ich rozmiaru.

          Jedną z prostszych czynności, jakie możemy wykonać, jest zmiana domyślnego rozmiaru dzienników transakcji. Jeśli plik ten jest zbyt mały, to zapełnia się zbyt często i dane są z niego bardzo często przesyłane, co zmniejsza wydajność bazy danych. Z kolei w przypadku zbyt dużych plików dziennika czas przesyłania danych może się niepotrzebnie wydłużyć. Rysunek 11.5 prezentuje plik dziennika na serwerze MariaDB 5.5, jego domyślny rozmiar wynosi 5 MB. Rozmiar ten został zwiększony w nowszych wersjach serwera MariaDB (począwszy od wersji 10.0) do 48 MB. W starszych wersjach bazy danych (np. 5.5) przed zmianą domyślnego rozmiaru musimy wyczyścić zawartość dzienników transakcji, przenosząc ją w odpowiednie miejsca tabel.

Dokonamy tego, zmuszając serwer do przetworzenia wszystkich wpisów dziennika transakcji i zapisania ich w plikach tabel w momencie wyłączania bazy danych. Zachowanie to jest  ontrolowane przez zmienną innodb_fast_shutdown, której wartość możemy zmodyfikować na działającym serwerze poprzez zalogowanie się na koncie administratora bazy danych i wysłanie kwerendy SET GLOBAL innodb_fast_shutdown = 1, 
tak jak pokazano w listingu 11.5.

Listing 11.5. Wymuszenie oczyszczania dziennika transakcji w czasie wyłączania serwera
MariaDB [(none)]> SET GLOBAL innodb_fast_shutdown = 1;
Query OK, 0 rows affected (0.00 sec)
Przekład:
Kwerenda OK, 0 zmodyfikowanych rekordów (0.00 sek)

Możemy teraz wyłączyć serwer MariaDB, dzięki czemu wszystkie oczekujące zmiany zostaną przeniesione z dzienników transakcji do plików tabel. Oznacza to, że nie muFsimy się już martwić, że uszkodzimy dane podczas zmiany rozmiaru dzienników cofnięć. W dystrybucji CentOS zatrzymamy bazę danych za pomocą komendy sudo systemctl stop mariadb. Omawiane dzienniki noszą nazwy ib_logfile0 oraz ib_logfile1; znajdziemy je w katalogu /var/lib/mysql. Przeniesiemy teraz obydwa te pliki, aby serwer MariaDB mógł utworzyć w ich miejsce nowe podczas jego
uruchomienia.

$ cd /var/lib/mysql/var/lib/mysql
$ sudo mv ib_logfile* /root

Następnie przechodzimy do edytowania pliku konfiguracji. W dystrybucji CentOS mieści się on w katalogu /etc/my.cnf.d/server.cnf. Nie ma w nim zbyt wiele treści, dlatego bez problemu możemy wstawić do niego zaprezentowane nieco niżej dyrektywy.
Dystrybucja Ubuntu zawiera wersję 10.0.31 serwera MariaDB. Domyślny rozmiar dzienników cofnięć wynosi 48 MB, więc generalnie nie trzeba go modyfikować. Jeśli jednak chcesz zmienić ich rozmiar, wystarczy edytować plik /etc/mysql/mysql.conf.d/mysqld.cnf oraz dodać/zmodyfikować parametr innodb_log_file_size, po czym należy uruchomić ponownie usługę mysql (tak, w dystrybucji Ubuntu na obecną chwilę bazę danychMariaDB utrzymuje usługa mysql).Poniższe zmiany wprowadzamy w sekcji [mysqld-5.5] (CentOS) lub [mysqld] (Ubuntu).

innodb_log_file_size = 48M
innodb_log_buffer_size = 16M
innodb_log_files_in_group = 2
innodb_buffer_pool_size = 128M
innodb_flush_method = O_DIRECT

Wyznaczamy rozmiar dziennika transakcji na 48 MB, a wewnętrznego bufora dziennika na 16 MB. Wartości te oznaczają, że serwer będzie wykorzystywał odrobinę więcej pamięci RAM, ale rzadziej będzie uzyskiwał dostęp do dysku, co poprawi ogólną wydajność. Następnie informujemy serwer MariaDB, że wykorzystywane są dwa dzienniki transakcji (innodb_log_files_in_group), co stanowi zresztą domyślną wartość. Musimy następnie przydzielić serwerowi pewną ilość pamięci RAM, w której będą przechowywane dane tabeli i przeprowadzane kwerendy. Wartość ta jest kontrolowana przez zmienną innodb_buffer_pool_size — wyznaczamy jej wartość 128 MB. Jest to rozsądny rozmiar pamięci na współczesnym komputerze obsługującym serwer MariaDB, a także inne usługi. Na ściśle wyspecjalizowanym serwerze wartość ta może stanowić do 80% całkowitej dostępnej pamięci. Możemy wyłączyć przechowywanie danych w pamięci podręcznej dysku za pomocą parametru innodb_flush_method. Mimo wszystko informacje te będą przechowywane w obszarze pamięci zarezerwowanym dla domyślnego bufora silnika InnoDB. Dzięki wartości 0_DIRECT uniemożliwiamy przechowywanie dwóch kopii danych w pamięci RAM poprzez regularne przesyłanie danych na dysk. Domyślnie zmienna ta jest nieużywana; dostępnych jest dla niej kilka różnych wartości. W zależności od sytuacji i wersji bazy danych możesz również wybrać opcję ALL_0_DIRECT (przydaje się do dużych plików podczas używania silnika InnoDB). Gdy dane nie znajdują się w pamięci RAM i muszą być przetwarzane z dysku, serwer MariaDB odczytuje je niewielkimi blokami o rozmiarze 128 kB. Zostaje w ten sposób zaoszczędzone użycie pamięci, ale odczyt dużych plików staje się bardzo czasochłonny. Zwiększymy rozmiar bloku odczytywanych danych za pomocą zmiennych

read_buffer_size i read_rnd_buffer_size.
read_buffer_size = 1M
read_rnd_buffer_size = 1M

Umożliwimy również serwerowi przeprowadzanie bardzo dużych kwerend, dzięki czemu będzie przechowywana większa ilość danych. Domyślną wartością jest 1 MB (w starszych wersjach); zwiększymy ją do 16 MB.

max_allowed_packet = 16M

Na koniec włączymy dziennik binarny za pomocą zmiennej log_bin. Ułatwi nam to odzyskiwanie danych w przypadku wystąpienia awarii.

log_bin = /var/log/mariadb/mariadb-bin.log
expire_logs_days = 14
max_binlog_size = 128M

Dzienniki binarne (ang. binary logs) używane są do replikowania transakcji bazodanowych. Rejestrowane są w nich instrukcje wstawiania, aktualizowania i usuwania; mogą być odtwarzane na serwerze dodatkowym w celu synchronizacji. Administratorzy są również w stanie za ich pomocą przywracać bazy danych z kopii zapasowych. W powyższym fragmencie wyznaczamy dwutygodniowy okres, po którym następuje wyczyszczenie dziennika binarnego. Oznacza to, że powinniśmy wykonywać kopię zapasową bazy danych MariaDB przynajmniej raz na czternaście dni (w rozdziale 14. nauczymy się automatyzować proces tworzenia kopii zapasowych). Informujemy również serwer, że ma zostać utworzony nowy dziennik binarny, gdy poprzedni osiągnie rozmiar 128 MB. W ten sposób łatwiej nam zarządzać tymi plikami i przesyłać je do serwera zapasowego lub trzeciorzędnego. Umieściliśmy je także w innym miejscu niż główne pliki bazodanowe, najlepiej zrobić to na osobnej partycji lub dysku. Zakończyliśmy podstawową konfigurację serwera MariaDB, zatem możemy go ponownie uruchomić, korzystając z komendy systemctl start mariadb (CentOS) lub sudo systemtctl start mysql (Ubuntu). Możemy sprawdzić, czy baza danych działa prawidłowo i utworzyła nowe pliki dzienników transakcji — w dystrybucji CentOS znajdują się one pod adresem /var/log/mariadb/mariadb.log; z kolei w dystrybucji Ubuntu znajdziemy je w katalogu /var/log/syslog. Pamiętaj, że nie skonfigurowaliśmy serwera MariaDB do pracy pod dużym obciążeniem; zmodyfikowaliśmy jedynie podstawowe ustawienia poprawiające spójność danych oraz nieznacznie zwiększające wydajność. Jeżeli interesuje Cię znaczące usprawnienie wydajności lub zaawansowane funkcje, takie jak replikacja danych pomiędzy wiele serwerów, zajrzyj do książki Wysoko wydajne MySQL. Optymalizacja, archiwizacja, replikacja.
Wydanie II autorstwa Barona Schwartza i in. (Helion, 2009)

LEAVE A REPLY

Please enter your comment!
Please enter your name here