Czy Immich może korzystać z zewnętrznej bazy danych bez problemów z aktualizacjami?

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.

Can Immich Use an External Database Without Breaking Upgrades? - Zima Store Online

Immich można skonfigurować tak, aby korzystał z zewnętrznej usługi PostgreSQL, ale nie sprawia to automatycznie, że aktualizacje będą bezpieczne; przenosi odpowiedzialność za wersję bazy danych, rozszerzenia, uprawnienia, kopie zapasowe i wycofywanie zmian poza domyślny stos.

Traktuj zewnętrzną bazę danych jako zaawansowaną granicę zgodności, a nie przełącznik wydajności. Przed każdą aktualizacją Immich lub PostgreSQL sprawdź wymagania dokładnej wersji Immich, którą planujesz uruchomić, potwierdź, że zewnętrzny serwer może zapewnić wymagane rozszerzenia i uprawnienia, wykonaj kopię zapasową możliwą do odtworzenia oraz zmieniaj jedną warstwę aktualizacji naraz, aby było wiadomo, który komponent spowodował awarię.

Zacznij od ustalenia warunków korzystania z zewnętrznej bazy danych

Udokumentuj punkt końcowy bazy danych, nazwę bazy, konto usługi, tryb TLS, główną wersję PostgreSQL, nazwy i wersje zainstalowanych rozszerzeń oraz osobę, która może je aktualizować. Przechowuj ten zapis obok definicji wdrożenia Immich, aby ponowne utworzenie kontenera nie spowodowało po cichu ponownego połączenia z innym serwerem lub inną bazą danych.

Istniejący serwer PostgreSQL jest możliwy do wykorzystania, ale nie jest domyślną zalecaną konfiguracją Immich. W bieżących wydaniach ścieżka z oddzielną bazą danych wymaga pgvector oraz VectorChord; wiadomo, że Immich działa z PostgreSQL w wersjach od 14 do 19, pgvector w wersji >=0.7 i <0.9 oraz VectorChord w wersji >=0.3 i <2.0. Sprawdzaj te zakresy ponownie przed każdą aktualizacją, ponieważ mogą się zmienić.

Zaplanuj uprawnienia przed przełączeniem. Immich zazwyczaj wymaga roli bazy danych z uprawnieniami administratora; uruchomienie bez nich jest zaawansowaną ścieżką, która może wymagać ręcznej interwencji podczas aktualizacji, a bieżące automatyczne kopie zapasowe bazy danych wymagają uprawnień administratora. Jeśli zewnętrzny dostawca nie może spełnić tych wymagań, zatrzymaj się przed przeniesieniem danych produkcyjnych.

Sprawdź zgodność PostgreSQL i rozszerzeń przed wprowadzeniem jakichkolwiek zmian

Wypisz bieżącą i docelową wersję PostgreSQL wraz ze wszystkimi rozszerzeniami, od których zależy Immich. Aktualizacja głównej wersji PostgreSQL może wymagać plików binarnych rozszerzeń zbudowanych dla docelowej wersji głównej, natomiast aktualizacja Immich może wymagać nowszego rozszerzenia lub innego działania migracji, nawet jeśli sam PostgreSQL nadal się uruchamia.

Pliki pakietów rozszerzeń oraz stan rozszerzeń SQL muszą być przenoszone wraz z bazą danych w sposób zaplanowany, a nie traktowane jako coś, co automatycznie podąży za aktualizacją PostgreSQL. Przed zmianą głównej wersji bazy danych lub pakietów rozszerzeń wymaganych przez Immich zapoznaj się z zależnościami związanymi z aktualizacją rozszerzeń PostgreSQL.

Jeśli zewnętrzny dostawca nie pozwala zainstalować lub zaktualizować wymaganego rozszerzenia, zmienić współdzielonych ustawień preload, gdy jest to konieczne, albo nadać uprawnień wymaganych przez migrację, zatrzymaj się przed aktualizacją Immich. Baza danych, która akceptuje zwykłe zapytania, nadal może nie nadawać się do wykonania następnej migracji aplikacji.

Przeprowadzaj główne aktualizacje bazy danych oddzielnie od aktualizacji Immich

Unikaj łączenia głównej aktualizacji PostgreSQL, aktualizacji rozszerzeń i aktualizacji aplikacji Immich w jednym oknie serwisowym, chyba że wcześniej przećwiczono całą sekwencję. Gdy kilka granic zgodności zmienia się jednocześnie, nieudane uruchomienie nie wskazuje już, która warstwa spowodowała problem.

Drobne aktualizacje PostgreSQL i aktualizacje głównej wersji to różne działania serwisowe, a przed główną aktualizacją należy przygotować środowisko docelowe, w tym rozszerzenia innych firm. W miarę możliwości przeprowadzaj aktualizacje głównej wersji PostgreSQL oddzielnie od aktualizacji aplikacji Immich, aby w razie nieudanego uruchomienia nadal istniała jedna jasno określona zmiana do zbadania.

W przypadku serwera domowego sekwencja o najniższym ryzyku zwykle wygląda następująco: wykonaj kopie zapasowe, sprawdź możliwość ich odtworzenia, zaktualizuj jedną warstwę, przeprowadź walidację, a następnie kontynuuj. Jeśli wydanie Immich wymaga zmiany bazy danych, postępuj zgodnie z kolejnością zalecaną dla tego wydania, zamiast stosować ogólną procedurę aktualizacji PostgreSQL.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zachowaj możliwość wycofania zmian obejmującą zarówno bazę danych, jak i multimedia

Zewnętrzna baza danych ułatwia zapomnienie, że stan Immich jest podzielony między PostgreSQL a bibliotekę multimediów. Przed migracją, która może zmienić schematy lub metadane zasobów, wykonaj kopię bazy danych spójną z jej stanem oraz zachowaj odpowiedni stan multimediów i konfiguracji z tego samego okna odzyskiwania.

Stan bazy danych, pliki aplikacji, konfiguracja i przesłane pliki muszą być ze sobą zgodne w momencie odtwarzania. Jako model akceptacji stosuj spójną kopię zapasową kontenera bazy danych, a nie tylko sprawdzaj, czy PostgreSQL się uruchamia.

Nie uznawaj wycofania zmian za gotowe, dopóki nie wiesz, co stanie się po obu stronach, jeśli migracja aplikacji zakończy się częściowo powodzeniem. Zachowaj starą wersję aplikacji, definicję wdrożenia, kopię bazy danych i stan multimediów wystarczająco długo, aby móc odzyskać dane bez nadpisywania jedynej znanej dobrej kopii nowszym stanem.

Weryfikuj aktualizację jako aplikację, a nie tylko połączenie z bazą danych

Po wprowadzeniu zmiany potwierdź, że PostgreSQL akceptuje zamierzoną rolę Immich, wymagane rozszerzenia są obecne w oczekiwanych wersjach, a migracja Immich kończy się bez powtarzających się błędów bazy danych. Udane połączenie TCP lub `SELECT 1` potwierdza łączność, a nie zgodność z aplikacją.

Następnie korzystaj z Immich w zwykły sposób: wczytaj stare albumy, otwórz przykładowe zdjęcia i filmy, wyszukaj dane, sprawdź użytkowników lub udostępnianie, jeśli ma to zastosowanie, oraz prześlij jeden nieistotny zasób. Podczas tych działań obserwuj dzienniki aplikacji i bazy danych pod kątem brakujących rozszerzeń, błędów uprawnień, nieudanych migracji lub powtarzających się prób.

Dopiero gdy aplikacja przejdzie te kontrole, przywróć zwykłą retencję kopii zapasowych i usuń kopię przeznaczoną do wycofania zmian. Jeśli zewnętrzna baza danych sprawia, że rutynowe aktualizacje Immich stale zależą od ręcznych prac związanych z rozszerzeniami lub uprawnieniami, których nie możesz niezawodnie przećwiczyć, bezpieczniejszym rozwiązaniem operacyjnym jest domyślny cykl życia dedykowanej bazy danych.