Kann Immich eine externe Datenbank verwenden, ohne Upgrades zu beeinträchtigen?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

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

Immich kann auf einen externen PostgreSQL-Dienst verwiesen werden, doch dadurch werden Upgrades nicht automatisch sicher. Die Verantwortung für Datenbankversion, Erweiterungen, Berechtigungen, Backups und Rollbacks wird lediglich aus dem Standard-Stack ausgelagert.

Betrachten Sie eine externe Datenbank als fortgeschrittene Kompatibilitätsschnittstelle, nicht als reine Leistungsoption. Prüfen Sie vor jedem Immich- oder PostgreSQL-Upgrade die Anforderungen der genauen Immich-Version, die Sie einsetzen möchten, bestätigen Sie, dass der externe Server die erforderlichen Erweiterungen und Berechtigungen bereitstellen kann, erstellen Sie ein wiederherstellbares Backup und ändern Sie jeweils nur eine Upgrade-Ebene, damit Sie wissen, welche Komponente einen Fehler verursacht hat.

Beginnen Sie mit der Vereinbarung für die externe Datenbank

Dokumentieren Sie den Datenbankendpunkt, den Datenbanknamen, das Dienstkonto, den TLS-Modus, die PostgreSQL-Hauptversion, die Namen und Versionen der installierten Erweiterungen sowie die Personen, die diese Erweiterungen aktualisieren dürfen. Bewahren Sie diesen Datensatz zusammen mit der Immich-Bereitstellungsdefinition auf, damit eine Neuerstellung des Containers nicht unbemerkt eine Verbindung zu einem anderen Server oder einer anderen Datenbank herstellt.

Ein bereits vorhandener PostgreSQL-Server ist möglich, entspricht jedoch nicht der standardmäßig empfohlenen Einrichtung von Immich. Für aktuelle Versionen erfordert der Betrieb mit einer eigenständigen Datenbank pgvector sowie VectorChord. Immich funktioniert bekanntermaßen mit PostgreSQL 14 bis 19, pgvector >=0.7 und <0.9 sowie VectorChord >=0.3 und <2.0. Prüfen Sie diese Bereiche vor jedem Upgrade erneut, da sie sich ändern können.

Planen Sie die Berechtigungen vor der Umstellung. Immich erwartet in der Regel eine Datenbankrolle mit Superuser-Berechtigungen. Der Betrieb ohne diese Berechtigungen ist ein fortgeschrittener Weg, der bei Aktualisierungen manuelle Eingriffe erfordern kann; aktuelle automatische Datenbank-Backups benötigen ebenfalls Superuser-Berechtigungen. Wenn Ihr externer Anbieter diese Anforderungen nicht erfüllen kann, halten Sie an, bevor Sie den Produktivzustand übertragen.

Überprüfen Sie die Kompatibilität von PostgreSQL und Erweiterungen, bevor Sie Änderungen vornehmen

Notieren Sie die aktuellen und angestrebten PostgreSQL-Versionen zusammen mit jeder Erweiterung, von der Immich abhängt. Ein Upgrade der PostgreSQL-Hauptversion kann Erweiterungs-Binärdateien erfordern, die für die Zielversion erstellt wurden. Ein Immich-Upgrade kann außerdem eine neuere Erweiterung oder ein bestimmtes Migrationsverhalten voraussetzen, selbst wenn PostgreSQL selbst weiterhin startet.

Die Paketdateien der Erweiterungen und der SQL-Status der Erweiterungen müssen bewusst zusammen mit der Datenbank aktualisiert werden, statt davon auszugehen, dass sie einem PostgreSQL-Upgrade automatisch folgen. Lesen Sie die Abhängigkeiten beim Aktualisieren von PostgreSQL-Erweiterungen, bevor Sie die Datenbank-Hauptversion oder die von Immich benötigten Erweiterungspakete ändern.

Wenn Ihr externer Anbieter Ihnen nicht erlaubt, die erforderliche Erweiterung zu installieren oder zu aktualisieren, bei Bedarf gemeinsam genutzte Preload-Einstellungen zu ändern oder die für die Migration erforderlichen Berechtigungen zu erteilen, halten Sie vor der Aktualisierung von Immich an. Eine Datenbank, die gewöhnliche Abfragen akzeptiert, kann dennoch für die nächste Anwendungsmigration ungeeignet sein.

Trennen Sie Upgrades der Datenbank-Hauptversion von Immich-Upgrades

Vermeiden Sie es, ein PostgreSQL-Upgrade der Hauptversion, ein Erweiterungs-Upgrade und ein Upgrade der Immich-Anwendung in einem Wartungsfenster zu kombinieren, sofern Sie die vollständige Abfolge nicht bereits erprobt haben. Wenn sich mehrere Kompatibilitätsgrenzen gleichzeitig verschieben, zeigt ein fehlgeschlagener Start nicht mehr, welche Ebene die Ursache war.

Minor-Updates von PostgreSQL und Upgrades der Hauptversion sind unterschiedliche Wartungsereignisse. Bei Upgrades der Hauptversion muss die Zielumgebung einschließlich Drittanbieter-Erweiterungen zunächst vorbereitet werden. Halten Sie Upgrades der PostgreSQL-Hauptversion nach Möglichkeit von einem Upgrade der Immich-Anwendung getrennt, damit ein fehlgeschlagener Start weiterhin eine klar abgrenzbare Änderung zur Untersuchung hinterlässt.

Für einen Heimserver lautet die risikoärmste Abfolge normalerweise: Backups erstellen, eine Wiederherstellung überprüfen, eine Ebene aktualisieren, eine Validierung durchführen und anschließend fortfahren. Wenn eine Immich-Version eine Datenbankänderung erfordert, befolgen Sie die für diese Version vorgeschriebene Reihenfolge, statt ein allgemeines PostgreSQL-Upgrade-Rezept anzuwenden.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Bewahren Sie einen Rollback-Weg für Datenbank und Medien

Bei einer externen Datenbank wird leicht vergessen, dass der Zustand von Immich auf PostgreSQL und die Medienbibliothek aufgeteilt ist. Sichern Sie die Datenbank mit einer datenbankkonsistenten Methode und bewahren Sie den relevanten Medien- und Konfigurationszustand aus demselben Wiederherstellungszeitraum auf, bevor Sie eine Migration durchführen, die Schemata oder Asset-Metadaten ändern kann.

Datenbankzustand, Anwendungsdateien, Konfiguration und Uploads müssen zum Zeitpunkt der Wiederherstellung zusammenpassen. Verwenden Sie ein konsistentes Backup eines laufenden Datenbank-Containers als Abnahmemodell, nicht lediglich die Frage, ob PostgreSQL startet.

Erklären Sie den Rollback erst dann für einsatzbereit, wenn Sie wissen, was mit beiden Seiten geschieht, falls die Anwendungsmigration nur teilweise erfolgreich ist. Halten Sie die alte Anwendungsversion, die Bereitstellungsdefinition, das Datenbank-Backup und den Medienzustand lange genug verfügbar, um eine Wiederherstellung durchzuführen, ohne neueren Zustand über die einzige bekannte funktionierende Kopie zu schreiben.

Validieren Sie das Upgrade als Anwendung, nicht nur als Datenbankverbindung

Bestätigen Sie nach der Änderung, dass PostgreSQL die vorgesehene Immich-Rolle akzeptiert, die erforderlichen Erweiterungen in den erwarteten Versionen vorhanden sind und die Immich-Migration ohne wiederholte Datenbankfehler abgeschlossen wird. Eine erfolgreiche TCP-Verbindung oder `SELECT 1` belegt die Konnektivität, nicht die Anwendungskompatibilität.

Verwenden Sie Immich anschließend wie gewohnt: Laden Sie alte Alben, öffnen Sie repräsentative Fotos und Videos, suchen Sie, überprüfen Sie gegebenenfalls Benutzer oder Freigaben und laden Sie ein nicht benötigtes Test-Asset hoch. Beobachten Sie während dieser Aktionen die Anwendungs- und Datenbankprotokolle auf fehlende Erweiterungen, Berechtigungsfehler, Migrationsfehler oder wiederholte Wiederholungsversuche.

Erst wenn die Anwendung diese Prüfungen besteht, sollten Sie die normale Backup-Aufbewahrung fortsetzen und die Rollback-Kopie entfernen. Wenn die externe Datenbank bei routinemäßigen Immich-Upgrades wiederholt manuelle Arbeiten an Erweiterungen oder Berechtigungen erfordert, die Sie nicht zuverlässig erproben können, ist der standardmäßige dedizierte Datenbanklebenszyklus die sicherere betriebliche Wahl.