Największe dni zakupów online w roku są tuż za rogiem. Czy Twoja baza danych jest gotowa? Dostrajając 20 kluczowych zmiennych systemowych MariaDB, zwiększysz wydajność swojej bazy danych , skalowalność i dostępność , zapewniając każdemu potencjalnemu klientowi płynną obsługę. Następujące zmienne systemowe pojawiają się wielokrotnie podczas konfigurowania optymalnego środowiska serwera MariaDB. Zastosuj nasze zalecenia dotyczące najbardziej dostrojonych wartości i uczyń tegoroczny okres Czarny Piątek – Cyberponiedziałek swoim najlepszym w historii.
Kilka ważnych uwag:
- Nie akceptuj tych sugestii ślepo. Każde środowisko MariaDB jest wyjątkowe i wymaga dodatkowego przemyślenia przed wprowadzeniem jakichkolwiek zmian. Najprawdopodobniej będziesz musiał dostosować te ustawienia do konkretnego przypadku użycia i środowiska.
- Plik konfiguracyjny MariaDB znajduje się w /etc/my.cnf. Za każdym razem, gdy modyfikujesz ten plik, musisz ponownie uruchomić usługę MySQL, aby nowe zmiany zaczęły obowiązywać.
20 zaleceń dotyczących tuningu w Czarny Piątek i Cyber Poniedziałek
1. Rozmiar puli buforów InnoDB
Rozmiar puli buforów InnoDB to ustawienie nr 1, które należy sprawdzić w przypadku dowolnej instalacji korzystającej z InnoDB. Pula buforów to miejsce, w którym buforowane są dane i indeksy; posiadanie go tak dużego, jak to możliwe, zapewni użycie pamięci, a nie dysków do większości operacji odczytu.
2. Rozmiar pliku dziennika InnoDB
innodb_log-file-size to rozmiar dzienników ponawiania, które służą do zapewniania, że zapisy są szybkie i trwałe. Istnieją dwie ogólne sugestie dotyczące rozmiaru pliku dziennika InnoDB:
- Ustaw łączny rozmiar plików dziennika InnoDB większy niż 25–50% rozmiaru puli buforów InnoDB
lub
- Ustaw łączny rozmiar dziennika pliku dziennika InnoDB równy liczbie wpisów dziennika z jednej godziny podczas szczytowego obciążenia
Większe pliki dziennika mogą spowolnić odzyskiwanie w przypadku awarii serwera. Jednak zmniejszają również liczbę wymaganych punktów kontrolnych i redukują liczbę operacji we/wy na dysku.
Oceń rozmiar jednogodzinnych dzienników binarnych pod obciążeniem operacyjnym, a następnie zdecyduj, czy zwiększyć rozmiar plików dziennika InnoDB.
Ustalenie odpowiednich rozmiarów plików dziennika innodb jest ważne dla osiągnięcia dobrej wydajności systemu. Aparat pamięci masowej InnoDB MariaDB wykorzystuje przestrzeń dziennika ponownego przetwarzania o stałym rozmiarze (okrągłą). Rozmiar jest kontrolowany przez innodb_log_file_size i innodb_log_files_in_group (domyślnie 2). Pomnóż te wartości, aby uzyskać dostępną do użycia przestrzeń dziennika ponownego wykonania. Chociaż technicznie nie powinno mieć znaczenia, czy użyjesz zmiennej innodb_log_file_size czy innodb_log_files_in_group do kontrolowania rozmiaru przestrzeni do ponownego wykonania, większość ludzi po prostu pracuje z innodb_log_file_size i zostawia innodb_log_files_in_group w spokoju.
Rozmiar przestrzeni ponawiania InnoDB jest jedną z najważniejszych opcji konfiguracyjnych dla obciążeń intensywnie korzystających z zapisu. Jednak wiąże się to z kompromisami. Im więcej skonfigurowanej przestrzeni do ponownego wykonania, tym lepiej InnoDB może zoptymalizować operacje we/wy zapisu. Jednak zwiększenie miejsca na ponowne wykonanie oznacza również dłuższe czasy przywracania, gdy system traci zasilanie lub ulega awarii z innych powodów.
3. Rozmiar bufora dziennika InnoDB
Większy rozmiar bufora dziennika InnoDB oznacza mniej operacji we/wy dysku dla większych transakcji. Sugeruje się ustawienie tego na 64M na wszystkich serwerach.
4. Interwał opróżniania dziennika InnoDB
Zmienna innodb_flush_log_at_trx_commit określa, kiedy następuje opróżnianie bufora dziennika na dysk. innodb_flush_log_at_trx_commit =1 (domyślnie) opróżnia bufor dziennika na dysk przy każdym zatwierdzeniu transakcji. Jest to najbezpieczniejsza, ale też najmniej wydajna opcja.
innodb_flush_log_at_trx_commit =0 opróżnia bufor dziennika na dysk co sekundę, ale nic przy zatwierdzaniu transakcji. Nawet jedna sekunda (prawdopodobnie więcej ze względu na planowanie procesów) może zostać utracona. W przypadku awarii MySQL lub serwer mogą utracić dane. To najszybsza, ale najmniej bezpieczna opcja.
innodb_flush_log_at_trx_commit =2 zapisuje bufor dziennika do pliku przy każdym zatwierdzeniu, ale co sekundę opróżnia się na dysk. Jeśli pamięć podręczna dysku ma zapasową baterię (na przykład bateryjny kontroler raid pamięci podręcznej), jest to zazwyczaj najlepsza równowaga między wydajnością a bezpieczeństwem. Awaria MySQL nie powinna spowodować utraty danych. Awaria serwera lub przerwa w zasilaniu może spowodować utratę nawet sekundy (prawdopodobnie więcej z powodu harmonogramu procesów). Pamięć podręczna podtrzymywana bateryjnie zmniejsza tę możliwość.
Sugerujemy użycie pierwszej opcji ze względów bezpieczeństwa.
5. Pojemność IO InnoDB
innodb_io_capacity należy ustawić na w przybliżeniu maksymalną liczbę IOPS, jaką może obsłużyć podstawowa pamięć masowa.
Domyślnie jest to 1000. Zalecamy przeprowadzenie testu porównawczego pamięci w celu ustalenia, czy można jeszcze bardziej zwiększyć tę wartość.
6. Rozmiar pamięci podręcznej wątków
Monitoruj wartość Threads_created. Jeśli nadal rośnie o więcej niż kilka wątków na minutę, zwiększ wartość thread_cache_size.
Rozmiar pamięci podręcznej wątków jest ustawiony na 200 w bieżącej domyślnej konfiguracji.
7. Pamięć podręczna tabeli i pamięć podręczna definicji tabeli
Zmienne table_open_cache i table_defintion_cache kontrolują liczbę tabel i definicji, które mają być otwarte dla wszystkich wątków.
Monitoruj Open_tables, Open_table_defintitions, Opened_tables i Opened_table_definitions, aby określić najlepszą wartość. Ogólną sugestią jest ustawienie table_open_cache (a następnie table_definition_cache) tylko na tyle wysokie, aby zmniejszyć tempo wzrostu wartości stanu Opened_tables (i Opened_table_definitions).
Zarówno table_open_cache, jak i table_defintion_cache są ustawione na 2048 w domyślnej konfiguracji.
8. Pamięć podręczna zapytań
Pamięć podręczna zapytań to dobrze znane wąskie gardło, które można zauważyć nawet przy umiarkowanej współbieżności. Najlepszą opcją jest wyłączenie go od pierwszego dnia, ustawiając query_cache_size =0 (wartość domyślna w MariaDB 10) i skorzystanie z innych sposobów przyspieszenia zapytań odczytu:dobre indeksowanie, dodawanie replik w celu rozłożenia obciążenia odczytu lub korzystanie z zewnętrznej pamięci podręcznej ( na przykład memcache lub redis). Jeśli masz już zbudowaną aplikację MariaDB z włączoną pamięcią podręczną zapytań i nigdy nie zauważyłeś żadnego problemu, pamięć podręczna zapytań może być dla Ciebie korzystna. W takim przypadku zachowaj ostrożność, jeśli zdecydujesz się go wyłączyć.
9. Tabele tymczasowe, tmp_table_size i max_heap_table_size
MySQL używa niższego z wartości max_heap_table_size i tmp_table_size, aby ograniczyć rozmiar tabel tymczasowych w pamięci. Są to zmienne na klienta. Duża wartość tej wartości może pomóc w zmniejszeniu liczby tabel tymczasowych tworzonych na dysku, ale zwiększa również ryzyko wykorzystania pojemności pamięci serwera, ponieważ dotyczy to jednego klienta. Ogólnie rzecz biorąc, sugerowaną wartością na początek dla obu zmiennych i dostrojeniem w razie potrzeby jest 32M do 64M.
Tabele tymczasowe są często używane dla GROUP BY, ORDER BY, DISTINCT, UNION, podzapytań itp. Idealnie byłoby, gdyby MySQL tworzył je w pamięci, z jak najmniejszą liczbą na dysku.
Należy pamiętać, że zapytania, które nie używają odpowiednio sprzężeń i tworzą duże tabele tymczasowe, mogą być jedną z przyczyn większej liczby tabel tymczasowych na dysku. Innym powodem jest to, że mechanizm przechowywania pamięci używa kolumn o stałej długości i przyjmuje najgorszy scenariusz. Jeśli kolumny mają nieprawidłowy rozmiar (na przykład VARCHAR(255) dla krótkiego ciągu), wpływa to na rozmiar tabeli w pamięci i może spowodować, że zostanie ona przeniesiona na dysk wcześniej niż powinna. Ponadto tabele tymczasowe z kolumnami typu blob i text zostaną natychmiast przeniesione na dysk, ponieważ mechanizm przechowywania pamięci ich nie obsługuje.
Oba są obecnie domyślnie ustawione na 64M.
10. Poziom dziennika ostrzeżeń
Zalecamy ustawienie tego poziomu dziennika ostrzeżeń na log_warnings =2. Spowoduje to rejestrowanie informacji o przerwanych połączeniach i błędach odmowy dostępu.
11. Maksymalna liczba połączeń
Jeśli często napotykasz błąd „Zbyt wiele połączeń”, wartość max_connections jest zbyt niska. Często, ponieważ aplikacja nie zamyka poprawnie połączeń z bazą danych, potrzeba znacznie więcej niż domyślne 151 połączeń. Główną wadą wysokich wartości dla max_connections (powiedzmy 1000 lub więcej) jest to, że serwer przestanie odpowiadać, jeśli będzie musiał uruchomić tyle aktywnych transakcji. Pomocne może tu być użycie puli połączeń na poziomie aplikacji lub puli wątków na poziomie MariaDB.
12. Izolacja transakcji
Zbadaj dostępne poziomy izolacji transakcji i określ najlepszą izolację transakcji dla przypadku użycia Twojego serwera.
13. Format dziennika binarnego
Zalecamy używanie formatu dziennika binarnego ROW do replikacji master-master.
14. Przesunięcia automatycznego przyrostu
Aby zmniejszyć ryzyko kolizji między dwoma wzorcami zapisywanymi jednocześnie, należy odpowiednio dostosować wartości automatycznego przyrostu i automatycznego przyrostu przesunięcia.
15. Synchronizuj Binlog
Domyślnie system operacyjny obsługuje opróżnianie binlogu na dysk. W przypadku awarii serwera istnieje możliwość utraty transakcji z dziennika binarnego, co prowadzi do braku synchronizacji replikacji. Ustawienie sync_binlog =1 powoduje, że plik binlog jest opróżniany przy każdym zatwierdzeniu.
To wolniejsza, ale najbezpieczniejsza opcja.
16. Crash Safe(r) Slave
Aby uniknąć błędów replikacji po awarii urządzenia podrzędnego, włącz odzyskiwanie dziennika przekaźnika i synchronizację plików dziennika przekaźnika i informacji dziennika przekaźnika z dyskiem.
17. Rejestruj aktualizacje Slave
Aby mieć replikację łańcuchową (master -> slave -> slave), należy włączyć log_slave_updates. Dzięki temu urządzenie podrzędne ma zapisywać zreplikowane transakcje we własnym dzienniku binarnym, aby można je było następnie zreplikować do urządzeń podrzędnych.
18. Niewolnicy tylko do odczytu
Slave powinny być tylko do odczytu, aby uniknąć przypadkowego zapisu do nich danych.
Uwaga :Użytkownicy z superuprawnieniami mogą nadal pisać, gdy serwer jest tylko do odczytu.
19. Limit czasu sieci podrzędnej
Zmienna slave_net_timeout to liczba sekund, przez które urządzenie podrzędne będzie czekać na pakiet od urządzenia nadrzędnego przed próbą ponownego połączenia. Wartość domyślna to 3600 (1 godzina). Oznacza to, że jeśli łącze zostanie przerwane i nie zostanie wykryte, ponowne połączenie urządzenia podrzędnego może potrwać do godziny. Może to doprowadzić do tego, że niewolnik będzie nagle o godzinę za mistrzem.
Zalecamy ustawienie slave_net_timeout na bardziej rozsądną wartość, na przykład 30 lub 60.
20. Obejrzyj nasze seminarium internetowe na temat przygotowań do Czarnego Piątku i Cyberponiedziałku
Obejrzyj nasze webinarium na żądanie – Przygotowanie do Czarnego Piątku i Cyberponiedziałku – aby poznać cztery podstawowe zasady przygotowania bazy danych: środki bezpieczeństwa aby chronić bazę danych przed złośliwymi atakami, dostrajanie wydajności aby zapewnić płynne wrażenia użytkownika, strategie wysokiej dostępności aby nie przegapić ani jednej sprzedaży i skalowalności przygotować się zarówno na przewidywany wzrost, jak i nieoczekiwane skoki.
