Producenci serwerów i dostawcy usług w chmurze oferują różne rodzaje rozwiązań pamięci masowej, aby zaspokoić Twoje potrzeby w zakresie baz danych. Kupując nowy serwer lub wybierając instancję w chmurze do uruchomienia naszej bazy, często zadajemy sobie pytanie – ile miejsca na dysku powinniśmy przeznaczyć? Jak się dowiemy, odpowiedź nie jest trywialna, ponieważ należy wziąć pod uwagę kilka aspektów. Miejsce na dysku to coś, o czym należy pomyśleć z góry, ponieważ zmniejszanie i powiększanie miejsca na dysku może być ryzykowną operacją dla bazy danych opartej na dyskach.
W tym poście na blogu przyjrzymy się, jak wstępnie określić wielkość przestrzeni dyskowej, a następnie zaplanować pojemność w celu obsługi wzrostu bazy danych MySQL lub MariaDB.
Jak MySQL wykorzystuje miejsce na dysku
MySQL przechowuje dane w plikach na dysku twardym w określonym katalogu, który ma zmienną systemową „datadir”. Zawartość katalogu danych będzie zależeć od wersji serwera MySQL oraz załadowanych parametrów konfiguracyjnych i zmiennych serwera (np. general_log, slow_query_log, log binarny).
Rzeczywiste informacje o przechowywaniu i pobieraniu zależą od silników pamięci masowej. W przypadku mechanizmu MyISAM indeksy tabeli są przechowywane w pliku .MYI, w katalogu danych, wraz z plikami .MYD i .frm tabeli. W przypadku silnika InnoDB indeksy są przechowywane w przestrzeni tabel wraz z tabelą. Jeśli innodb_file_per_table jest ustawiona, indeksy będą znajdować się w pliku .ibd tabeli wraz z plikiem .frm. W przypadku silnika pamięci dane są przechowywane w pamięci (stercie), podczas gdy struktura jest przechowywana w pliku .frm na dysku. W nadchodzącym MySQL 8.0 pliki metadanych (.frm, .par, dp.opt) zostaną usunięte wraz z wprowadzeniem nowego schematu słownika danych.
Należy zauważyć, że jeśli używasz współdzielonego obszaru tabel InnoDB do przechowywania danych tabeli (innodb_file_per_table=OFF ), oczekuje się, że fizyczny rozmiar danych MySQL będzie stale rósł, nawet po obcięciu lub usunięciu ogromnych wierszy danych. Jedynym sposobem na odzyskanie wolnego miejsca w tej konfiguracji jest wyeksportowanie, usunięcie bieżących baz danych i ponowne zaimportowanie ich z powrotem za pomocą mysqldump. Dlatego ważne jest, aby ustawić innodb_file_per_table=ON jeśli martwisz się o miejsce na dysku, więc podczas obcinania tabeli można odzyskać miejsce. Ponadto przy tej konfiguracji ogromna operacja DELETE nie zwolni miejsca na dysku, chyba że później zostanie wykonana OPTIMIZE TABLE.
MySQL przechowuje każdą bazę danych we własnym katalogu pod ścieżką „datadir”. Ponadto pliki dziennika i inne powiązane pliki MySQL, takie jak pliki gniazd i PID, domyślnie będą również tworzone w katalogu datadir. Ze względu na wydajność i niezawodność zaleca się przechowywanie plików dziennika MySQL na osobnym dysku lub partycji - zwłaszcza dziennika błędów MySQL i dzienniki binarne.
Szacowanie rozmiaru bazy danych
Podstawowym sposobem szacowania rozmiaru jest znalezienie współczynnika wzrostu między dwoma różnymi punktami w czasie, a następnie pomnożenie tego przez bieżący rozmiar bazy danych. Mierzenie ruchu w bazie danych w godzinach szczytu w tym celu nie jest najlepszą praktyką i nie odzwierciedla wykorzystania bazy danych jako całości. Pomyśl o operacji wsadowej lub procedurze składowanej uruchamianej o północy lub raz w tygodniu. Twoja baza danych może potencjalnie znacznie wzrosnąć rano, zanim prawdopodobnie zostanie zmniejszona przez operację porządkową o północy.
Jednym z możliwych sposobów jest użycie naszych kopii zapasowych jako podstawowego elementu tego pomiaru. Fizyczna kopia zapasowa, taka jak Percona Xtrabackup, MariaDB Backup i migawka systemu plików, zapewnia dokładniejszą reprezentację rozmiaru bazy danych w porównaniu z kopią logiczną, ponieważ zawiera binarną kopię bazy danych i indeksów. Logiczna kopia zapasowa, taka jak mysqldump, przechowuje tylko instrukcje SQL, które można wykonać w celu odtworzenia oryginalnych definicji obiektów bazy danych i danych tabel. Niemniej jednak nadal możesz uzyskać dobry wskaźnik wzrostu, porównując kopie zapasowe mysqldump.
Aby oszacować rozmiar bazy danych, możemy użyć następującego wzoru:
Gdzie,
- B - Rozmiar pełnej kopii zapasowej z bieżącego tygodnia,
- B - Pełny rozmiar kopii zapasowej z poprzedniego tygodnia,
- Dbdane - Całkowity rozmiar danych bazy danych,
- Dbindeks - Całkowity rozmiar indeksu bazy danych,
- 52 - Liczba tygodni w roku,
- T - Rok.
Całkowity rozmiar bazy danych (dane i indeksy) w MB można obliczyć za pomocą następujących instrukcji:
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+Powyższe równanie można zmodyfikować, jeśli chcesz zamiast tego korzystać z miesięcznych kopii zapasowych. Zmień stałą wartość z 52 na 12 (12 miesięcy w roku) i gotowe.
Nie zapomnij też uwzględnić innodb_log_file_size x 2, innodb_data_file_path a w przypadku Galera Cluster dodaj gcache.size wartość.
Oszacowanie rozmiaru dzienników binarnych
Dzienniki binarne są generowane przez system główny MySQL do celów replikacji i odzyskiwania do określonego momentu. Jest to zbiór plików logów, które zawierają informacje o modyfikacjach danych dokonanych na serwerze MySQL. Rozmiar dzienników binarnych zależy od liczby operacji zapisu i formatu dziennika binarnego - STATEMENT, ROW lub MIXED. Dziennik binarny oparty na instrukcjach jest zwykle znacznie mniejszy w porównaniu z dziennikiem binarnym opartym na wierszach, ponieważ składa się tylko z instrukcji write, podczas gdy dziennik oparty na wierszach składa się ze zmodyfikowanych informacji o wierszach.
Najlepszym sposobem oszacowania maksymalnego wykorzystania dysku przez dzienniki binarne jest zmierzenie rozmiaru dziennika binarnego na dzień i pomnożenie go przez expire_logs_days wartość (domyślnie 0 - brak automatycznego usuwania). Ważne jest, aby ustawić expire_logs_days dzięki czemu możesz poprawnie oszacować rozmiar. Domyślnie każdy dziennik binarny jest ograniczony do około 1 GB, zanim MySQL obróci plik dziennika binarnego. Możemy użyć zdarzenia MySQL, aby po prostu opróżnić dziennik binarny w celu oszacowania.
Po pierwsze, upewnij się, że zmienna event_scheduler jest włączona:
mysql> SET GLOBAL event_scheduler = ON;Następnie, jako uprzywilejowany użytkownik (z uprawnieniami EVENT i RELOAD), utwórz następujące zdarzenie:
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;W przypadku obciążenia intensywnie korzystającego z zapisu prawdopodobnie trzeba skrócić interwał do 30 minut lub 10 minut, zanim dziennik binarny osiągnie maksymalny rozmiar 1 GB, a następnie zaokrąglić dane wyjściowe do godziny. Następnie zweryfikuj status zdarzenia za pomocą poniższej instrukcji i spójrz na kolumnę LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Następnie spójrz na logi binarne, które mamy teraz:
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Następnie możemy obliczyć średni wzrost naszych logów binarnych, który wynosi około ~562 MB na godzinę w godzinach szczytu. Pomnóż tę wartość przez 24 godziny i expire_logs_days wartość:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Otrzymamy 94416 MB, czyli około ~95 GB miejsca na dysku na nasze logi binarne. Dzienniki przekaźnika urządzenia podrzędnego są w zasadzie takie same, jak dzienniki binarne urządzenia nadrzędnego, z wyjątkiem tego, że są przechowywane po stronie urządzenia podrzędnego. Dlatego te obliczenia dotyczą również dzienników przekaźników podrzędnych.
Dysk wrzeciona czy półprzewodnikowy?
Istnieją dwa rodzaje operacji we/wy na plikach MySQL:
- Pliki sekwencyjne we/wy:
- Przestrzeń tabel systemu InnoDB (ibdata)
- Pliki dziennika MySQL:
- Dzienniki binarne (binlog.xxxx)
- Redo dzienniki (ib_logfile*)
- Dzienniki ogólne
- Dzienniki wolnych zapytań
- Dziennik błędów
- Losowe pliki zorientowane na We/Wy:
- Plik danych InnoDB file-per-table (*.ibd) z innodb_file_per_table=ON (domyślnie).
Rozważ umieszczenie losowych plików zorientowanych na operacje we/wy w podsystemie dyskowym o wysokiej przepustowości, aby uzyskać najlepszą wydajność. Może to być dysk flash – albo dyski SSD lub karta NVRAM, albo dyski wrzecionowe o wysokiej prędkości obrotowej, takie jak SAS 15K lub 10K, ze sprzętowym kontrolerem RAID i jednostką podtrzymywaną bateryjnie. W przypadku sekwencyjnych plików zorientowanych na operacje we/wy przechowywanie na dysku twardym z podtrzymywaną bateryjnie pamięcią podręczną zapisu powinno wystarczyć dla MySQL. Pamiętaj, że w przypadku rozładowania baterii prawdopodobne jest pogorszenie wydajności.
Omówimy ten obszar (szacowanie przepustowości dysku i alokacji plików) w osobnym poście.
Planowanie pojemności i wymiarowanie
Planowanie wydajności może nam pomóc w zbudowaniu produkcyjnego serwera bazy danych z wystarczającą ilością zasobów, aby przetrwać codzienne operacje. Musimy również uwzględnić nieoczekiwane potrzeby, uwzględnić przyszłe potrzeby w zakresie pamięci masowej i przepustowości dysków. Dlatego planowanie pojemności jest ważne, aby baza danych miała wystarczająco dużo miejsca do oddychania do następnego cyklu odświeżania sprzętu.
Najlepiej zilustrować to przykładem. Biorąc pod uwagę następujący scenariusz:
- Następny cykl sprzętowy:3 lata
- Obecny rozmiar bazy danych:2013 MB
- Obecny rozmiar pełnej kopii zapasowej (tydzień N):1177 MB
- Poprzedni rozmiar pełnej kopii zapasowej (tydzień N-1):936 MB
- Rozmiar delta:241 MB na tydzień
- Współczynnik delta:przyrost 25,7% na tydzień
- Łączna liczba tygodni w ciągu 3 lat:156 tygodni
- Oszacowanie całkowitego rozmiaru bazy danych:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB po 3 latach
Jeśli używasz logów binarnych, zsumuj je z wartości, którą otrzymaliśmy w poprzedniej sekcji:
- 81 + 95 =176 GB miejsca na logi bazy danych i binarnych.
Dodaj co najmniej 100% więcej miejsca na zadania operacyjne i konserwacyjne (lokalna kopia zapasowa, przemieszczanie danych, dziennik błędów, pliki systemu operacyjnego itp.):
- 176 + 176 =352 GB całkowitej przestrzeni dyskowej.
Na podstawie tego oszacowania możemy stwierdzić, że przez 3 lata potrzebowalibyśmy co najmniej 352 GB miejsca na dysku dla naszej bazy danych. Możesz użyć tej wartości, aby uzasadnić zakup nowego sprzętu. Na przykład, jeśli chcesz kupić nowy serwer dedykowany, możesz wybrać 6 x 128 SSD RAID 10 z podtrzymywanym bateryjnie kontrolerem RAID, który zapewni około 384 GB całkowitej przestrzeni dyskowej. Lub, jeśli wolisz chmurę, możesz uzyskać 100 GB pamięci blokowej z aprowizowanymi IOPS dla naszej bazy danych 81 GB i użyć standardowej trwałej pamięci blokowej dla naszych dzienników binarnych 95 GB i innych zastosowań operacyjnych.
Miłego wymiarowania!
