Jak naprawić Immich po zapełnieniu woluminu bazy danych

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Repair Immich After Its Database Volume Fills Up - Zima Store Online

Gdy wolumin bazy danych Immich się zapełni, zatrzymaj nowe zapisy Immich, zabezpiecz katalog danych PostgreSQL i utwórz bezpieczną przestrzeń roboczą przed podjęciem próby odzyskiwania. Nie usuwaj plików z pg_wal ani innych wewnętrznych elementów PostgreSQL tylko dlatego, że zajmują dużo miejsca.

Pełny system plików bazy danych może przerwać punkty kontrolne lub odzyskiwanie po awarii, dlatego kolejne ponowne uruchomienia mogą nadal kończyć się niepowodzeniem, nawet jeśli sama aplikacja do zdjęć wygląda na sprawną. Najpierw ustal, który system plików jest pełny — dane PostgreSQL, główny magazyn Dockera, pamięć współdzielona czy inny punkt montowania — a następnie napraw tę warstwę bez niszczenia dowodów, które mogą być potrzebne do wycofania zmian.

Potwierdź, który system plików jest pełny, i zatrzymaj dalsze zapisy

Sprawdź dostępność miejsca i i-węzłów dla punktu montowania PostgreSQL, katalogu danych Dockera, głównego systemu plików hosta oraz każdej ścieżki tmpfs/pamięci współdzielonej wymienionej w komunikacie o błędzie. Porównaj znacznik czasu z dziennikami PostgreSQL. Komunikat „no space left on device” z pg_wal oznacza coś innego niż pełna pamięć podręczna obrazów lub partycja miniatur.

W dyskusji dotyczącej odzyskiwania bazy danych Immich opisano przerwanie odzyskiwania przez PostgreSQL, ponieważ po zapełnieniu pamięci masowej nie można było zapisać tymczasowego pliku WAL. Przypadek jest stary i zależny od konkretnego wdrożenia, ale pokazuje, dlaczego zmiana uprawnień do plików lub ponowne uruchomienie stosu nie naprawia problemu z brakiem miejsca.

Wstrzymaj przesyłanie plików i zadania w tle, a następnie zatrzymaj komponenty aplikacji generujące nowe operacje na bazie danych. Zachowaj pierwszy fragment dziennika z błędem oraz mapę punktów montowania. Jeśli pełny system plików nie jest w rzeczywistości systemem plików danych PostgreSQL, napraw właściwą lokalizację zamiast niepotrzebnie przenosić bazę danych.

Zabezpiecz stan PostgreSQL przed zwolnieniem miejsca

Po zatrzymaniu PostgreSQL wykonaj migawkę systemu plików lub pełną kopię katalogu danych bazy danych, o ile pozwalają na to dostępne miejsce i używane narzędzia. Uwzględnij katalog WAL oraz wszystkie nietypowe przestrzenie tabel jako jeden stan. Ta kopia bezpieczeństwa pozwoli wrócić do momentu wystąpienia incydentu, jeśli kolejna próba odzyskiwania pogorszy sytuację.

Wskazówki dotyczące odzyskiwania PostgreSQL po wyczerpaniu miejsca jasno określają najważniejszą zasadę: WAL jest częścią spójności bazy danych, a nie zwykłymi zbędnymi dziennikami, dlatego ręczne usuwanie tych plików może uszkodzić bazę danych. Zamiast tego uzyskaj miejsce przez rozszerzenie lub przeniesienie woluminu albo usunięcie innych bezpiecznych danych. Nie nadpisuj od razu uszkodzonej bazy danych ostatnią kopią zapasową, chyba że uznasz bieżący stan za niemożliwy do odzyskania i akceptujesz utratę zmian od czasu wykonania tej kopii. Zachowanie zapełnionej instancji zapewnia zarówno punkt wycofania zmian, jak i dowody wyjaśniające, dlaczego zabrakło miejsca.

Najpierw odzyskaj PostgreSQL, a dopiero potem zdecyduj, czy Immich wymaga naprawy

Gdy będzie dostępna wystarczająca ilość miejsca, uruchom PostgreSQL samodzielnie lub z minimalnym wymaganym stosem i obserwuj dzienniki odzyskiwania. Prawidłowe uruchomienie, pomyślna kontrola stanu oraz normalny dostęp do odczytu są mocniejszymi sygnałami niż status kontenera „running”. Gdy tylko baza danych będzie wystarczająco stabilna, wykonaj nową kopię zapasową w formacie natywnym dla bazy danych.

Przewodnik ZimaSpace dotyczący konserwacji lub wymiany bazy danych Immich wyznacza kolejną granicę: zwykłe problemy z rozmiarem lub wydajnością nie powinny prowadzić do odbudowy, natomiast powtarzalne problemy ze spójnością lub odzyskiwaniem mogą uzasadniać przywrócenie zweryfikowanej kopii bazy danych.

Uruchom Immich dopiero wtedy, gdy PostgreSQL będzie nadal działać prawidłowo.

Sprawdź użytkowników, oś czasu, kilka oryginalnych plików, albumy, wyszukiwanie oraz jedno kontrolowane nowe przesłanie. Jeśli baza danych uruchamia się, ale zapytania aplikacji stale kończą się niepowodzeniem, zachowaj nowe dzienniki i ustal, czy aktywnym problemem jest teraz zgodność schematu/wersji lub integralność danych, a nie brak wolnego miejsca.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Usuń przyczynę rozrostu i sprawdź, czy system może znów bezpiecznie się zapełniać

Zmierz, która część urosła: zwykłe tabele bazy danych, retencja WAL, kopie zapasowe przechowywane na tym samym woluminie, dzienniki, warstwy Dockera czy nieoczekiwana ścieżka. Jeśli przyczyną incydentu był nieudany proces archiwizacji/replikacji lub inna usługa zapisująca dane w woluminie bazy danych, napraw tę przyczynę, zamiast jedynie zwiększać pojemność.

Ustaw alerty na długo przed zapełnieniem woluminu do poziomu, przy którym PostgreSQL nie może wykonać punktu kontrolnego ani odzyskiwania. Monitoruj zarówno wartość procentową, jak i bezwzględną ilość wolnego miejsca, ponieważ duży wolumin może mieć niewielki procent wolnego miejsca, a mimo to wystarczającą przestrzeń roboczą, podczas gdy mały wolumin bazy danych może szybko stać się niebezpieczny. Przechowuj kopie zapasowe bazy danych poza tą samą granicą awarii, przed którą mają chronić.

Na koniec powtórz zwykły cykl przesyłania plików i przetwarzania w tle, utwórz nową kopię zapasową bazy danych, uruchom ponownie stos i zrestartuj hosta. Test można uznać za pomyślny, gdy spadek ilości wolnego miejsca jest stabilny, nie występują błędy WAL/odzyskiwania, stare i nowe zasoby są dostępne do odczytu, a udokumentowany próg uruchamia działania, zanim zapisy ponownie przestaną działać.