Oznaki wskazujące, że baza danych Immich wymaga konserwacji lub wymiany

Baza danych Immich, która jest jedynie powolna, może wymagać rutynowej konserwacji PostgreSQL lub usunięcia problemu z zasobami; baza danych wykazująca powtarzające się błędy integralności lub odzyskiwania może wymagać przywrócenia albo zastąpienia na podstawie zweryfikowanej kopii zapasowej.

Nie używaj określenia „przebudować bazę danych” jako ogólnego rozwiązania problemów z wydajnością. Najpierw odróżnij normalny wzrost, nadmiarowe dane, nieaktualne statystyki, zablokowaną konserwację i opóźnienia pamięci masowej od uszkodzenia lub niemożliwego do odzyskania stanu klastra. Przed inwazyjnymi działaniami zachowaj punkt odzyskiwania, mierz efekt każdej zmiany konserwacyjnej osobno i przejdź do czystego przywrócenia dopiero wtedy, gdy dowody wskazują, że bieżącej bazie danych nie można ufać lub nie da się jej bezpiecznie naprawić.

Oddziel pogorszenie wydajności od awarii integralności

Zacznij od dokładnego objawu: wolnego wyszukiwania, wolnych zapytań osi czasu, dużego rozmiaru bazy danych, dużej aktywności dysku, powtarzających się błędów PostgreSQL, pętli odzyskiwania po awarii lub migracji Immich, której nie można ukończyć. Objawy wydajnościowe i objawy problemów z integralnością wiążą się z różnym ryzykiem i nie powinny prowadzić do tego samego pierwszego działania naprawczego.

Upewnij się, że host nadal korzysta ze sprawnej pamięci masowej, ma wystarczająco dużo wolnego miejsca i prawidłowe zachowanie pamięci oraz że żadne zadanie działające w tle w Immich nie wymknęło się spod kontroli, zanim obwinisz PostgreSQL. Przeciążony lub uszkodzony dysk może sprawić, że zdrowa baza danych będzie wyglądać na powolną, a także może rzeczywiście doprowadzić do jej uszkodzenia, jeśli podstawowa pamięć masowa stanie się zawodna.

Przed inwazyjną konserwacją zachowaj logi, wersję bazy danych, wersje rozszerzeń, historię ostatnich aktualizacji oraz kopię zapasową lub migawkę. Jeśli jedyna kopia bazy danych może być uszkodzona, nie uruchamiaj destrukcyjnego czyszczenia tylko po to, by sprawdzić, czy błąd zniknie; zachowaj dowody potrzebne do podjęcia kontrolowanej decyzji o przywróceniu.

Szukaj mierzalnych sygnałów potrzeby konserwacji

Rutynowa konserwacja staje się prawdopodobnym rozwiązaniem, gdy baza danych uruchamia się i pozostaje wewnętrznie użyteczna, ale wydajność zapytań lub zajętość dysku pogarsza się z czasem. Przydatne dowody obejmują rosnącą liczbę martwych wierszy, tabele lub indeksy, których rozmiar rośnie nieproporcjonalnie, autovacuum, które nie nadąża, nieaktualne statystyki planera lub długotrwałą konserwację blokowaną przez inne sesje.

Martwe krotki, nadmiarowe dane, presja zamrażania, zablokowane VACUUM i niewystarczająca częstotliwość odkurzania mogą wpływać na konserwację PostgreSQL i wydajność zapytań. Korzystaj z sygnałów VACUUM na poziomie tabel w czasie, zamiast zakładać, że sam duży plik bazy danych dowodzi potrzeby jej zastąpienia.

Jeśli statystyki wskazują jedną tabelę lub indeks, wybierz najmniej inwazyjne, obsługiwane działanie konserwacyjne odpowiednie dla tego ustalenia i ponownie wykonaj pomiary. Nie przechodź od razu do VACUUM FULL, szeroko zakrojonych operacji REINDEX ani przypadkowego dostrajania autovacuum w całym klastrze; działania te mogą powodować blokady, operacje wejścia-wyjścia lub dodatkowe zapotrzebowanie na miejsce na dysku, a także mogą nie rozwiązać rzeczywistego wąskiego gardła.

Sprawdź, czy nadmiarowe dane lub rozrost indeksu odpowiadają za powolną ścieżkę

Porównaj obiekty związane z powolnymi operacjami Immich z rozmiarem tabel i indeksów, zmianami liczby wierszy oraz zachowaniem zapytań. Nadmiarowe dane mają znaczenie, gdy zwiększają nakład pracy potrzebny do znalezienia użytecznych wierszy lub sprawiają, że indeksy działają mniej skutecznie, ale baza danych może być duża również po prostu dlatego, że duża jest biblioteka i ilość metadanych.

Nadmiarowe dane w tabelach i indeksach należy oceniać osobno, ponieważ ich nadmiar może zwiększać nakład pracy zapytań, nie oznaczając uszkodzenia bazy danych. Użyj pomiarów nadmiarowych danych PostgreSQL, aby skupić się na zaobserwowanym obiekcie i w razie potrzeby odświeżyć statystyki planera, zamiast traktować całkowity rozmiar bazy danych jako diagnozę.

Po konserwacji ponownie wykonaj dokładnie tę operację Immich, która działała wolno, i porównaj zarówno opóźnienie odczuwalne przez użytkownika, jak i zachowanie bazy danych oraz pamięci masowej. Jeśli operacja się nie poprawi, w miarę możliwości przywróć poprzednie dostrojenie i zbadaj pamięć masową, wzorce zapytań, zadania w tle lub przyczyny na poziomie aplikacji, zamiast nakładać kolejne zmiany w bazie danych.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Przejdź do przywracania lub zastąpienia, gdy integralność jest niepewna

Zastąpienie jest uzasadnione dowodami, że bieżącemu stanowi PostgreSQL nie można ufać lub nie da się go bezpiecznie odzyskać, a nie samym wiekiem. Przykłady obejmują powtarzalne uszkodzenia stron lub sum kontrolnych, błędy uruchamiania lub odzyskiwania utrzymujące się na sprawnej pamięci masowej, uszkodzenie klastra po niepełnym zdarzeniu związanym z pamięcią masową albo stan migracji, którego nie można naprawić obsługiwaną metodą.

Zanim uznasz bazę danych za utraconą, sprawdź, czy znaną dobrą kopię zapasową można przywrócić do czystego, zgodnego środowiska PostgreSQL oraz czy Immich może ją odczytać. Jeśli czyste przywrócenie działa, a bieżący klaster powtarza ten sam błąd integralności, masz znacznie mocniejsze podstawy, by zastąpić stan bazy danych, zamiast kontynuować naprawę w miejscu.

Naprawiaj lokalne, odwracalne usterki, zachowując niepewny trwały stan; przebudowuj tylko wtedy, gdy źródło odzyskiwania jest zweryfikowane, a środowisko docelowe można odtworzyć. Zastosuj tę granicę między naprawą a przebudową Immich również do bazy danych. „Zastąpienie” powinno oznaczać przywrócenie zgodnego stanu PostgreSQL ze znanego, dobrego źródła, a nie zmianę bazy danych tylko dlatego, że zapytanie stało się wolne.

Zweryfikuj bazę danych za pomocą operacji odczytu, zapisu i tworzenia kopii zapasowej

Niezależnie od tego, czy przeprowadzono konserwację, czy przywrócono czystą bazę danych, zweryfikuj wynik w Immich, a nie tylko na podstawie pomyślnego uruchomienia PostgreSQL. Otwórz stare albumy i zasoby, wykonaj wyszukiwanie, wczytaj reprezentatywne nagrania wideo i sprawdź, czy użytkownicy oraz stan udostępniania są zgodne z oczekiwaniami.

Wykonaj jeden bezpieczny nowy zapis, na przykład prześlij zasób przeznaczony do usunięcia, i potwierdź, że pozostaje dostępny po normalnym ponownym uruchomieniu usługi. Obserwuj logi PostgreSQL i Immich pod kątem powtarzających się błędów integralności, migracji, rozszerzeń lub uprawnień, gdy aktywne są ścieżki odczytu i zapisu.

Na koniec utwórz świeżą kopię zapasową bazy danych zwykłą metodą i, jeśli to praktyczne, przetestuj jej przywrócenie w odizolowanym środowisku docelowym. Decyzja o konserwacji lub zastąpieniu jest zakończona dopiero wtedy, gdy bieżący system jest użyteczny, a kolejny punkt odzyskiwania jest wyraźnie zdrowszy niż stan, który wywołał incydent.