Kan Immich een externe database gebruiken zonder upgrades te verstoren?

Immich kan naar een externe PostgreSQL-service verwijzen, maar daardoor worden upgrades niet automatisch veilig; de verantwoordelijkheid voor databaseversies, extensies, rechten, back-ups en terugdraaien komt buiten de standaardstack te liggen.

Beschouw een externe database als een geavanceerde compatibiliteitsgrens, niet als een simpel vinkje voor betere prestaties. Controleer vóór elke upgrade van Immich of PostgreSQL de vereisten van de exacte Immich-release die je wilt gebruiken, bevestig dat de externe server de vereiste extensies en rechten kan leveren, maak een herstelbare back-up en wijzig telkens slechts één upgradeniveau, zodat je weet welk onderdeel een probleem heeft veroorzaakt.

Begin met het contract voor de externe database

Documenteer het database-eindpunt, de databasenaam, het serviceaccount, de TLS-modus, de hoofdversie van PostgreSQL, de namen en versies van geïnstalleerde extensies en wie die extensies mag upgraden. Bewaar dit overzicht naast de implementatiedefinitie van Immich, zodat het opnieuw aanmaken van een container niet ongemerkt verbinding maakt met een andere server of database.

Een bestaande PostgreSQL-server is mogelijk, maar dit is niet de standaard aanbevolen configuratie van Immich. Voor huidige releases vereist het pad met een zelfstandige database pgvector en VectorChord; het is bekend dat Immich werkt met PostgreSQL 14 tot en met 19, pgvector >=0.7 en <0.9, en VectorChord >=0.3 en <2.0. Controleer deze bereiken vóór elke upgrade opnieuw, omdat ze kunnen veranderen.

Plan de rechten vóór de omschakeling. Immich verwacht doorgaans een databaserol met superuserrechten; uitvoeren zonder die rechten is een geavanceerd pad waarvoor tijdens updates handmatige interventie nodig kan zijn, en voor de huidige geautomatiseerde databaseback-ups zijn superuserrechten vereist. Als je externe provider niet aan deze vereisten kan voldoen, stop dan voordat je productiedata verplaatst.

Controleer de compatibiliteit van PostgreSQL en extensies voordat je iets wijzigt

Noteer de huidige en doelversies van PostgreSQL samen met elke extensie waarvan Immich afhankelijk is. Een upgrade van de hoofdversie van PostgreSQL kan extensiebinaries vereisen die voor de doelversie zijn gebouwd, terwijl een upgrade van Immich een nieuwere extensie of ander migratiegedrag kan vereisen, zelfs als PostgreSQL zelf nog steeds opstart.

Pakketbestanden van extensies en de SQL-status van extensies moeten bewust samen met de database worden gemigreerd; ga er niet van uit dat ze een PostgreSQL-upgrade automatisch volgen. Bekijk de afhankelijkheden voor het upgraden van PostgreSQL-extensies voordat je de hoofdversie van de database wijzigt of de extensiepakketten installeert die Immich vereist.

Als je externe provider je niet toestaat de vereiste extensie te installeren of te upgraden, gedeelde preload-instellingen te wijzigen wanneer dat nodig is, of de rechten toe te kennen die voor de migratie nodig zijn, stop dan voordat je Immich bijwerkt. Een database die gewone query's accepteert, kan nog steeds ongeschikt zijn voor de volgende applicatiemigratie.

Houd upgrades van de hoofdversie van de database gescheiden van Immich-upgrades

Combineer een upgrade van de hoofdversie van PostgreSQL, een extensie-upgrade en een upgrade van de Immich-applicatie niet in één onderhoudsmoment, tenzij je de volledige reeks al hebt geoefend. Wanneer meerdere compatibiliteitsgrenzen tegelijk verschuiven, vertelt een mislukte start niet meer welke laag de oorzaak was.

Kleine PostgreSQL-updates en upgrades van de hoofdversie zijn verschillende onderhoudsmomenten, en vóór een upgrade van de hoofdversie moet de doelomgeving—inclusief extensies van derden—eerst worden voorbereid. Houd upgrades van de hoofdversie van PostgreSQL waar mogelijk gescheiden van een upgrade van de Immich-applicatie, zodat een mislukte start nog steeds één duidelijke wijziging heeft die je kunt onderzoeken.

Voor een homeserver is de route met het minste risico meestal: back-ups maken, een herstel controleren, één laag bijwerken, validatie uitvoeren en daarna doorgaan. Als een Immich-release een databasewijziging vereist, volg dan de voorgeschreven volgorde van die release in plaats van een algemene PostgreSQL-upgradeprocedure toe te passen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Behoud een terugdraaipad voor zowel de database als media

Bij een externe database is het makkelijker om te vergeten dat de status van Immich is verdeeld over PostgreSQL en de mediabibliotheek. Maak een databaseconsistente back-up van de database en bewaar de relevante media- en configuratiestatus uit hetzelfde herstelvenster voordat je een migratie uitvoert die schema's of metagegevens van assets kan wijzigen.

Databasestatus, applicatiebestanden, configuratie en uploads moeten op het moment van herstel met elkaar overeenkomen. Gebruik een consistente back-up van de databasecontainer als acceptatiemodel, niet alleen de vraag of PostgreSQL opstart.

Beschouw terugdraaien pas als gereed wanneer je weet wat er met beide kanten gebeurt als de applicatiemigratie gedeeltelijk slaagt. Houd de oude applicatieversie, implementatiedefinitie, databaseback-up en mediadatastatus lang genoeg beschikbaar om te kunnen herstellen zonder nieuwere gegevens over de enige bekende goede kopie heen te schrijven.

Valideer de upgrade als applicatie, niet alleen als databaseverbinding

Controleer na de wijziging of PostgreSQL de bedoelde Immich-rol accepteert, of de vereiste extensies aanwezig zijn met de verwachte versies en of de Immich-migratie zonder terugkerende databasefouten is voltooid. Een geslaagde TCP-verbinding of `SELECT 1` bewijst connectiviteit, maar geen compatibiliteit met de applicatie.

Gebruik Immich daarna zoals je dat normaal doet: laad oude albums, open representatieve foto's en video's, zoek, controleer gebruikers of delen waar dat relevant is en upload één wegwerpbestand. Houd tijdens deze handelingen de applicatie- en databaselogboeken in de gaten voor ontbrekende extensies, rechtenfouten, migratiefouten of herhaalde pogingen.

Pas nadat de applicatie deze controles heeft doorstaan, hervat je de normale bewaartermijnen voor back-ups en verwijder je de terugdraaikopie. Als de externe database ervoor zorgt dat routinematige Immich-upgrades herhaaldelijk afhankelijk zijn van handmatig extensie- of rechtenwerk dat je niet betrouwbaar kunt oefenen, is de standaardlevenscyclus met een eigen database operationeel de veiligere keuze.