Kan Immich använda en extern databas utan att uppgraderingar slutar fungera?

Immich kan riktas mot en extern PostgreSQL-tjänst, men det gör inte uppgraderingar automatiskt säkra; det flyttar ansvaret för databasversion, tillägg, behörigheter, säkerhetskopiering och återställning utanför standardstacken.

Betrakta en extern databas som en avancerad kompatibilitetsgräns, inte som en prestandafunktion. Före varje uppgradering av Immich eller PostgreSQL ska du kontrollera kraven för den exakta Immich-versionen du planerar att köra, bekräfta att den externa servern kan tillhandahålla nödvändiga tillägg och behörigheter, skapa en återställningsbar säkerhetskopia och ändra ett uppgraderingslager i taget så att du vet vilken komponent som orsakat ett fel.

Börja med avtalet för den externa databasen

Dokumentera databasens slutpunkt, databasnamn, tjänstekonto, TLS-läge, PostgreSQL-huvudversion, installerade tilläggs namn och versioner samt vem som kan uppgradera dessa tillägg. Förvara dokumentationen tillsammans med Immich-distributionens definition så att en återskapad container inte i tysthet ansluter till en annan server eller databas.

En befintlig PostgreSQL-server är möjlig, men den är inte Immichs standardmässigt rekommenderade konfiguration. För aktuella versioner kräver vägen med en fristående databas pgvector samt VectorChord; Immich är känt för att fungera med PostgreSQL 14 till 19, pgvector >=0.7 och <0.9 samt VectorChord >=0.3 och <2.0. Kontrollera dessa intervall på nytt före varje uppgradering eftersom de kan ändras.

Planera behörigheterna före övergången. Immich förväntar sig vanligtvis en databasroll med superanvändarbehörighet; att köra utan den är en avancerad väg som kan kräva manuella åtgärder under uppdateringar, och aktuella automatiserade databassäkerhetskopior kräver superanvändarbehörighet. Om din externa leverantör inte kan uppfylla dessa krav ska du avbryta innan du flyttar produktionsdata.

Verifiera kompatibilitet mellan PostgreSQL och tillägg innan du ändrar något

Lista de aktuella och målversionerna av PostgreSQL tillsammans med alla tillägg som Immich är beroende av. En större PostgreSQL-uppgradering kan kräva tilläggsbibliotek som är byggda för målversionen, medan en Immich-uppgradering kan kräva ett nyare tillägg eller ett annat migreringsbeteende även om PostgreSQL självt fortfarande startar.

Tilläggens paketfiler och SQL-tilläggens tillstånd måste flyttas medvetet tillsammans med databasen i stället för att man antar att de följer med en PostgreSQL-uppgradering. Läs om beroenden vid uppgradering av PostgreSQL-tillägg innan du ändrar databasens huvudversion eller paketen för de tillägg som Immich kräver.

Om din externa leverantör inte låter dig installera eller uppgradera det nödvändiga tillägget, ändra delade preload-inställningar när det krävs eller bevilja de behörigheter som migreringen behöver, ska du avbryta innan du uppdaterar Immich. En databas som accepterar vanliga frågor kan ändå vara olämplig för nästa applikationsmigrering.

Håll större databasuppgraderingar åtskilda från Immich-uppgraderingar

Undvik att kombinera en större PostgreSQL-uppgradering, en tilläggsuppgradering och en Immich-applikationsuppgradering i samma underhållstillfälle, om du inte redan har övat hela sekvensen. När flera kompatibilitetsgränser flyttas samtidigt visar en misslyckad start inte längre vilket lager som orsakat felet.

Mindre PostgreSQL-uppdateringar och uppgraderingar till en ny huvudversion är olika underhållshändelser, och större uppgraderingar kräver att målmiljön – inklusive tredjepartstillägg – förbereds först. Håll uppgraderingar till en ny PostgreSQL-huvudversion åtskilda från en Immich-applikationsuppgradering när det är möjligt, så att en misslyckad start fortfarande har en tydlig förändring att undersöka.

För en hemmaserver är den minst riskfyllda ordningen vanligtvis: skapa säkerhetskopior, verifiera en återställning, uppdatera ett lager, kör validering och fortsätt sedan. Om en Immich-version kräver en databasändring ska du följa den versionens föreskrivna ordning i stället för att tillämpa en generell PostgreSQL-uppgraderingsmetod.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Bevara en återställningsväg som omfattar både databasen och mediefilerna

En extern databas gör det lättare att glömma att Immichs tillstånd är uppdelat mellan PostgreSQL och mediebiblioteket. Säkerhetskopiera databasen med en databaskonsistent metod och bevara relevant media- och konfigurationstillstånd från samma återställningsfönster före en migrering som kan ändra scheman eller metadata för mediefiler.

Databastillstånd, applikationsfiler, konfiguration och uppladdningar måste överensstämma vid återställning. Använd en konsekvent säkerhetskopia av databaskontainern som acceptanskriterium, inte bara huruvida PostgreSQL startar.

Förklara inte återställning som redo förrän du vet vad som händer med båda sidorna om applikationsmigreringen lyckas delvis. Behåll den gamla applikationsversionen, distributionsdefinitionen, databassäkerhetskopian och medietillståndet tillräckligt länge för att kunna återställa utan att skriva nyare tillstånd över den enda kända fungerande kopian.

Validera uppgraderingen som en applikation, inte bara som en databasanslutning

Efter ändringen ska du bekräfta att PostgreSQL accepterar den avsedda Immich-rollen, att nödvändiga tillägg finns i förväntade versioner och att Immich-migreringen slutförs utan upprepade databasfel. En fungerande TCP-anslutning eller `SELECT 1` bevisar anslutning, inte applikationskompatibilitet.

Använd sedan Immich normalt: läs in gamla album, öppna representativa foton och videor, sök, granska användare eller delning där det är relevant och ladda upp en testfil som kan raderas. Övervaka applikations- och databasloggar under dessa åtgärder efter saknade tillägg, behörighetsfel, migreringsfel eller upprepade försök.

Först när applikationen har klarat dessa kontroller bör du återgå till normal lagringstid för säkerhetskopior och ta bort återställningskopian. Om den externa databasen upprepade gånger gör vanliga Immich-uppgraderingar beroende av manuellt arbete med tillägg eller behörigheter som du inte pålitligt kan öva på, är den standardiserade livscykeln med en dedikerad databas det säkrare valet ur driftssynpunkt.