Przejdź do treści

MySQL – optymalizacja i wydajność

O pracy MySQL DBA – przemyślenia administratora

Archiwa

Kategoria: MySQL

Replikacja – słowo klucz które utożsamiane jest z zaawansowaną technologię, skalowalnością, wysoką dostępnością danych. Wszystko zapowiada się znakomicie, projekt aplikacji wygląda pięknie na slajdach Keynote czy Powerpointa, przełożeni są oszołomieni możliwościami, jakie roztacza ta technologia. Pytanie tylko, czy replikacja faktycznie jest dla Ciebie?
czytaj dalej…

Czasami, w trakcie prac administracyjnych, pojawia się taka konieczność zmiany nazwy tabeli czy bazy danych. W jaki sposób można to zrobić w przypadku MySQL?
Jeśli chodzi o zmianę nazwy tabeli sprawa jest łatwa:

RENAME TABLE tabela1 TO tabela2;

Czy można zmienić w podobny sposób nazwę bazy danych?

czytaj dalej…

Pewien czas temu miałem okazję zetknąć się z kolejnym przeciążonym serwerem. Ni z tego ni z owego obciążenie podsystemu dyskowego wzrosło kilkukrotnie, co spowodowało praktycznie pad całej maszyny fizycznej. Na szczęście serwer był monitorowany, tak więc miałem dostęp do danych z pewnego okresu czasu dotyczących stanu serwera – widać w nich było pewien wzrost zapotrzebowania na pamięć przez serwer Apache, który współdzielił serwer z MySQL. Co się stało?
czytaj dalej…

Dziś bardzo krótko, tak tylko w ramach przypomnienia dla tych, którzy śledzą bloga od niedawna i nie przeglądali archiwalnych postów. Lista IN() – wygodna konstrukcja, która zazwyczaj jest szybka i wydajna. Problem pojawia się w momencie, gdy zamiast listy argumentów do IN() wrzucimy podzapytanie. Dlaczego to jest złe, pisałem dokładnie w tym poście:

Lista IN() i podzapytania

Wspominam o tym ponownie, bo po raz kolejny miałem okazję widzieć serwer umierający pod naporem tego typu zapytań. Zapytań, które można stosunkowo prosto przepisać i które mogą być wydajne. Tyle tylko że w trochę innej postaci niż ta najbardziej „logiczna” z punktu widzenia SQL i programisty. Pamiętajmy o tym że optimizer MysQL nie koniecznie jest logiczny. Aby pisać wydajne zapytania trzeba znać jego mocne i słabe strony, nie wystarczy napisać poprawny kod SQL.

MySQL, aby przyspieszyć wgrywanie danych udostępnia przydatną funkcję – wyłącza indeksy. Dzięki temu, podczas wgrywania danych do tabeli nie ma potrzeby przebudowywania struktury indeksu po każdym INSERTcie. Po wgraniu danych włączamy obsługę indeksów i są one odbudowywane raz, w momencie gdy wszystkie dane są już na miejscu w tabeli.
czytaj dalej…

Czasami zdarza się sytuacja, w której trzeba szybko przenieść dane z serwera na serwer. Wykonanie zrzutu i wgranie go niestety trwa. Co można zrobić aby przyspieszyć ten proces? Rozwiązaniem jest po prostu przegranie plików z serwera na serwer. Zazwyczaj rsync plików z danymi pomiędzy serwerami będzie znacznie szybszy niż dump/reload. Jak to wygląda w praktyce i na co trzeba uważać?
czytaj dalej…

Co pewien czas natykam się na slowlogi z zapytaniami typu:

DESCRIBE tabela;
SHOW COLUMNS FROM tabela;
# administrator command: Ping;

Skąd się one pojawiają, skoro twórca aplikacji nie przypomina sobie, aby tego typu zapytania generował?

czytaj dalej…

W poprzednim poście opisywałem w jaki sposób skonfigurować replikację pomiędzy serwerami MySQL w sytuacji, gdy oba serwery są puste. Wiemy, że do skonfigurowania replikacji potrzebujemy informacje o tym, w którym miejscu binlogów powinna się ona rozpocząć. Dziś bardziej życiowy problem – mamy jeden serwer na którym produkcyjnie działa jakaś baza danych. Tą bazę chcemy replikować. Jak się za to zabrać? Problem sprowadza się do tego, że trzeba uzyskać na slave dokładny obraz bazy mastera dla danego, konkretnego miejsca w binlogu. Nie jeden INSERT później, czy też wcześniej. Co można zrobić?
czytaj dalej…

Chwilę temu na tym blogu pojawiły się dwa posty (ten i ten), które opisywały zasadę działania mechanizmu replikacji zastosowanego w MySQL. Pisałem tam, że zajmiemy się także tym, w jaki sposób konfiguruje się serwery MySQL aby replikacja działała poprawnie. Zajmiemy się tym dziś właśnie.

czytaj dalej…

Rozgrzewka

Sty 24

Jak powszechnie wiadomo, zanim człowiek jest w stanie osiągnąć maksymalny poziom wysiłku fizycznego dobrze jest się wcześniej rozgrzać. Podobnie jest z MySQL. Świeżo uruchomiony serwer MySQL to często dziesiątki gigabajtów cache i buforów, które czekają na zapełnienie. Dane znajdują się na dysku i muszą być dopiero wczytane do pamięci. W przypadku dużej ilości danych i dużych ilości pamięci ten proces trwa długo i przez ten czas serwer nie funkcjonuje z największą możliwą wydajnością. Przygotowałem krótki benchmark który, mam nadzieję, pokaże wyraźnie dlaczego ten cały „hot start” jest taki ważny.
czytaj dalej…