Jak zatrzymać rozrost kontenera bazy danych po oczyszczeniu danych

Kontener bazy danych może nadal rosnąć po usunięciu danych, ponieważ usunięte wiersze, dzienniki transakcji, indeksy i dzienniki kontenera podlegają różnym zasadom odzyskiwania miejsca.

Nie zakładaj, że wolumin bazy danych rośnie tylko dlatego, że całkowity rozmiar kontenera na dysku się zwiększa. Zmierz osobno katalog danych bazy, katalogi WAL lub binlogów, plik dziennika Dockera, zapisywalną warstwę kontenera oraz ścieżki kopii zapasowych i plików tymczasowych. Następnie ustal, czy usunięte miejsce w bazie można ponownie wykorzystać wewnętrznie, ale nie jest zwracane systemowi hosta, czy rzeczywiście wymagane jest przepisanie danych, albo czy nadal rośnie zupełnie inny plik.

Zmierz, która ścieżka nadal rośnie

Zapisz rozmiar nazwanego woluminu lub katalogu bazy danych zamontowanego przez bind mount, zapisywalnej warstwy kontenera, dziennika kontenera po stronie hosta, katalogu dzienników transakcji bazy danych oraz dowolnego katalogu zrzutów lub plików tymczasowych przed jednym cyklem czyszczenia i po nim.

Poradnik rozwiązywania problemów z miejscem na dysku PostgreSQL zaczyna się od tej samej zasady: najpierw znajdź miejsce zajmujące przestrzeń, a dopiero potem wybierz metodę odzyskiwania miejsca.

Jeśli rośnie tylko dziennik Dockera, czyszczenie bazy danych nie ma znaczenia. Jeśli plik danych pozostaje duży, ale po czyszczeniu przestaje się zwiększać, silnik może już ponownie wykorzystywać zwolnione strony, mimo że system plików hosta nie widzi zmniejszenia rozmiaru.

Rozróżnij miejsce możliwe do ponownego wykorzystania od miejsca zwróconego na dysk

Wiele transakcyjnych baz danych nie usuwa natychmiast bloków plików ze środka tabeli po usunięciu wierszy. Oznaczają one strony wewnętrzne jako możliwe do ponownego wykorzystania, aby późniejsze wstawienia mogły użyć tego miejsca, podczas gdy rozmiar pliku bazowego pozostaje bez zmian.

PostgreSQL stanowi wyraźny przykład: zwykły VACUUM ponownie wykorzystuje miejsce wewnętrznie, ale zazwyczaj nie zwraca tych środkowych obszarów pliku systemowi operacyjnemu.

Obserwuj, czy plik nadal rośnie podczas nowych wstawień po czyszczeniu. Stabilny rozmiar pliku przy malejącym wewnętrznym przerostie to coś innego niż niekontrolowany wzrost i zwykle nie uzasadnia awaryjnego przepisywania danych.

Użyj metody odzyskiwania miejsca właściwej dla silnika bazy, a nie ogólnego czyszczenia Dockera

Jeśli celem jest zwrócenie miejsca systemowi hosta, najpierw ustal silnik bazy danych i format przechowywania. PostgreSQL, MySQL lub MariaDB oraz SQLite nie korzystają z jednego zamiennego polecenia zmniejszania rozmiaru, a niektóre operacje odzyskiwania miejsca przepisują duże pliki lub blokują tabele.

Artykuł o przechowywaniu danych MySQL wyjaśnia, jak OPTIMIZE może przebudować tabele InnoDB, zamiast traktować polecenie DELETE jako dowód, że host powinien natychmiast odzyskać bajty.

Przed każdą operacją wymagającą intensywnego przepisywania wykonaj kopię zapasową bazy danych i potwierdź dostępność wolnego miejsca roboczego. Prawie pełny dysk domowego serwera to najgorszy moment na uruchamianie polecenia, które potrzebuje drugiej kopii dużej tabeli.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź osobno WAL, binlogi i retencję replikacji

Dzienniki transakcji mogą rosnąć nawet po usunięciu starych wierszy aplikacji. Nieudane zadanie archiwizacji, nieaktualny slot replikacji, opóźniona replika, długa transakcja lub wymagania dotyczące przechowywania kopii zapasowych mogą zatrzymywać historyczne segmenty dzienników na dysku.

Niedawna notatka dotycząca odzyskiwania PostgreSQL pokazuje, jak retencja WAL może zajmować miejsce niezależnie od danych tabeli, które użytkownik właśnie wyczyścił.

Nie usuwaj ręcznie plików WAL ani binlogów z systemu plików. Usuń przyczynę nadmiernej retencji za pomocą silnika bazy danych, a następnie sprawdź, czy normalne ponowne wykorzystywanie dzienników zostało wznowione.

Ogranicz dzienniki Dockera i sprawdź zapisywalną warstwę

Kontener bazy danych może sprawiać wrażenie, że rośnie, ponieważ dane stdout lub stderr są zapisywane w nieograniczonym dzienniku Dockera albo dlatego, że tymczasowy eksport, pamięć podręczna lub plik bazy danych trafiły do warstwy kontenera zamiast do przeznaczonego do tego trwałego woluminu.

Opis przypadku związanego z samodzielnie hostowanym Dockerem wskazuje, że dzienniki kontenerów mogą rosnąć bez końca, gdy rotacja nie jest skonfigurowana.

Przed usunięciem czegokolwiek przypisz każdy duży plik na hoście do jego ścieżki w kontenerze. Skonfiguruj rotację dzienników, aby zapobiec dalszemu wzrostowi, i przenieś stan bazy danych do jawnie zdefiniowanego woluminu zamiast polegać na nietrwałej warstwie zapisywalnej.

Sprawdź, czy czyszczenie zapewnia trwały zapas miejsca

Po wykonaniu wybranej operacji odzyskiwania miejsca uruchom zwykłe obciążenie zapisu przez reprezentatywny czas i porównaj wolne miejsce na hoście, rozmiar plików bazy danych, rozmiar dzienników transakcji, dzienniki Dockera oraz wewnętrzne wskaźniki wolnego miejsca lub przerostu.

Poradnik zmniejszania rozmiaru bazy PostgreSQL podkreśla, że zmniejszenie wymaga ukierunkowanej konserwacji, zamiast zakładać, że każde usunięcie danych powinno natychmiast zmniejszyć rozmiar pliku w systemie operacyjnym.

Problem można uznać za rozwiązany, gdy oczekiwany wzrost bazy danych jest ponownie wykorzystywany lub ograniczony, a host nie traci niewyjaśnionego miejsca po każdym cyklu czyszczenia. Powiązany poradnik ZimaSpace dotyczący spójnych kopii zapasowych kontenera bazy danych wyznacza punkt przywracania przed każdą operacją przepisywania plików bazy.

Najczęściej zadawane pytania

Dlaczego usunięcie milionów wierszy czasami zwalnia niemal zero miejsca na dysku hosta?

Silnik może oznaczyć te strony jako możliwe do ponownego wykorzystania wewnątrz pliku bazy danych, zamiast skrócić sam plik. Dzięki temu można zapobiec przyszłemu wzrostowi, ale rozmiar pliku widoczny dla hosta pozostaje bez zmian.

Czy za każdym razem, gdy kontener staje się duży, powinienem wykonywać pełne przepisanie danych?

Nie. Operacje wymagające intensywnego przepisywania mogą wymagać blokad, miejsca tymczasowego i znacznej ilości operacji wejścia-wyjścia. Używaj ich tylko wtedy, gdy zwrócenie miejsca hostowi jest konieczne i znasz zagrożenia właściwe dla danego silnika.

Czy polecenie Docker prune może odzyskać miejsce zajmowane przez wolumin bazy danych?

Nie jest to bezpieczne, gdy wolumin nadal stanowi część trwałego stanu bazy danych. Przed czyszczeniem ustal, czy miejsce zajmują dzienniki, obrazy, zatrzymane kontenery czy aktywne dane bazy.