Anzeichen dafür, dass eine Immich-Datenbank Wartung oder einen Austausch benötigt

Eine Immich-Datenbank, die lediglich langsam ist, benötigt möglicherweise routinemäßige PostgreSQL-Wartung oder eine Anpassung der Ressourcen. Eine Datenbank, bei der wiederholt Integritäts- oder Wiederherstellungsfehler auftreten, muss möglicherweise aus einem verifizierten Backup wiederhergestellt oder ersetzt werden.

Verwende „Datenbank neu aufbauen“ nicht als allgemeine Lösung für Performance-Probleme. Unterscheide zunächst zwischen normalem Wachstum, Bloat, veralteten Statistiken, blockierter Wartung und Speicherlatenz einerseits sowie beschädigten oder nicht wiederherstellbaren Cluster-Zuständen andererseits. Sichere vor invasiven Arbeiten einen Wiederherstellungspunkt, miss jeweils nur eine Wartungsänderung und führe erst dann eine saubere Wiederherstellung durch, wenn die Anzeichen darauf hindeuten, dass der aktuellen Datenbank nicht vertraut werden kann oder sie nicht sicher reparierbar ist.

Performance-Abbau von Integritätsfehlern unterscheiden

Beginne mit dem genauen Symptom: langsame Suchen, langsame Timeline-Abfragen, eine große Datenbank, hohe Festplattenaktivität, wiederholte PostgreSQL-Fehler, Schleifen bei der Crash-Wiederherstellung oder eine Immich-Migration, die nicht abgeschlossen werden kann. Performance- und Integritätssymptome bergen unterschiedliche Risiken und sollten nicht dieselbe erste Reparaturmaßnahme erhalten.

Stelle sicher, dass der Host weiterhin über funktionierenden Speicher, ausreichend freien Speicherplatz und ein normales Speicherverhalten verfügt und kein außer Kontrolle geratener Immich-Hintergrundjob läuft, bevor du PostgreSQL die Schuld gibst. Ein überlastetes oder fehlerhaftes Laufwerk kann eine gesunde Datenbank langsam erscheinen lassen und bei unzuverlässigem zugrunde liegendem Speicher auch echte Datenbankschäden verursachen.

Sichere vor invasiver Wartung die Logs, die Datenbankversion, die Erweiterungsversionen, die jüngste Upgrade-Historie sowie ein Backup oder einen Snapshot. Wenn die einzige Datenbankkopie möglicherweise beschädigt ist, führe keine destruktive Bereinigung nur zu Testzwecken aus. Bewahre stattdessen die für eine kontrollierte Entscheidung über die Wiederherstellung erforderlichen Belege auf.

Messbare Hinweise auf Wartungsbedarf erkennen

Routinemäßige Wartung wird wahrscheinlich, wenn die Datenbank startet und intern weiterhin nutzbar ist, sich aber die Abfrageleistung oder der Speicherbedarf im Laufe der Zeit verschlechtert. Nützliche Hinweise sind zunehmende tote Zeilen, Tabellen oder Indizes, die unverhältnismäßig wachsen, ein nicht nachkommendes Autovacuum, veraltete Optimizer-Statistiken oder lang laufende Wartung, die durch andere Sitzungen blockiert wird.

Tote Tupel, Bloat, Freezing-Druck, blockiertes VACUUM und eine unzureichende VACUUM-Häufigkeit können sich auf die PostgreSQL-Wartung und die Abfrageleistung auswirken. Nutze VACUUM-Signale auf Tabellenebene über einen längeren Zeitraum, anstatt allein aufgrund einer großen Datenbankdatei anzunehmen, dass die Datenbank ersetzt werden muss.

Wenn die Statistiken auf eine bestimmte Tabelle oder einen bestimmten Index hinweisen, wähle für diesen Befund die am wenigsten invasive unterstützte Wartungsmaßnahme und miss anschließend erneut. Vermeide es, direkt zu VACUUM FULL, umfassenden REINDEX-Vorgängen oder willkürlichen Autovacuum-Anpassungen für den gesamten Cluster zu greifen. Diese Maßnahmen können Sperren, I/O-Last oder zusätzlichen Speicherbedarf verursachen und möglicherweise den eigentlichen Engpass nicht beheben.

Prüfen, ob Bloat oder Indexwachstum zum langsamen Pfad passt

Vergleiche die an langsamen Immich-Vorgängen beteiligten Objekte mit der Größe von Tabellen und Indizes, der Änderungshäufigkeit von Zeilen und dem Abfrageverhalten. Bloat ist relevant, wenn dadurch der Aufwand steigt, nützliche Zeilen zu finden, oder Indizes weniger effektiv werden. Die Datenbank kann jedoch auch einfach deshalb groß sein, weil die Mediathek und die Metadaten umfangreich sind.

Tabellen- und Index-Bloat sollten getrennt bewertet werden, da übermäßiger Bloat den für Abfragen erforderlichen Aufwand erhöhen kann, ohne auf eine beschädigte Datenbank hinzudeuten. Nutze messbare PostgreSQL-Bloat-Prüfungen, um ein beobachtetes Objekt gezielt zu untersuchen, und aktualisiere die Optimizer-Statistiken, wo dies angemessen ist, anstatt die Gesamtdatenbankgröße als Diagnose zu betrachten.

Führe nach der Wartung genau den langsamen Immich-Vorgang erneut aus und vergleiche sowohl die für Benutzer sichtbare Latenz als auch das Verhalten von Datenbank und Speicher. Wenn sich der Vorgang nicht verbessert, setze die Anpassungen nach Möglichkeit zurück und untersuche Speicher, Abfragemuster, Hintergrundjobs oder Ursachen auf Anwendungsebene, anstatt weitere Datenbankänderungen anzuhäufen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Bei unsicherer Integrität auf Wiederherstellung oder Ersatz umsteigen

Ein Ersatz ist durch Hinweise gerechtfertigt, dass dem aktuellen PostgreSQL-Zustand nicht vertraut werden kann oder er nicht sicher wiederherstellbar ist, nicht allein durch sein Alter. Beispiele sind wiederholbare Seiten- oder Prüfsummenfehler, Start- oder Wiederherstellungsfehler, die auf gesundem Speicher bestehen bleiben, ein beschädigter Cluster nach einem unvollständigen Speicherereignis oder ein Migrationszustand, der über den unterstützten Weg nicht repariert werden kann.

Bevor du die Datenbank für verloren erklärst, stelle nachweislich sicher, dass ein bekannt gutes Backup in einer sauberen, kompatiblen PostgreSQL-Umgebung wiederhergestellt werden kann und Immich darauf zugreifen kann. Wenn die saubere Wiederherstellung funktioniert, während der aktuelle Cluster denselben Integritätsfehler wiederholt, ist dies ein deutlich stärkeres Argument dafür, den Datenbankzustand zu ersetzen, statt die Reparatur im laufenden System fortzusetzen.

Repariere lokale, reversible Fehler, während du den unsicheren persistenten Zustand bewahrst. Baue ihn nur neu auf, wenn die Wiederherstellungsquelle verifiziert und das Ziel reproduzierbar ist. Wende diese Grenze zwischen Reparatur und Neuaufbau bei Immich auch auf die Datenbank an. „Ersatz“ sollte bedeuten, einen kompatiblen PostgreSQL-Zustand aus einer bekannten guten Quelle wiederherzustellen, nicht die Datenbank zu wechseln, weil eine Abfrage langsam geworden ist.

Die Datenbank durch Lese-, Schreib- und Backup-Vorgänge validieren

Unabhängig davon, ob du Wartungsarbeiten durchgeführt oder eine saubere Datenbank wiederhergestellt hast, solltest du das Ergebnis über Immich prüfen, statt dich auf einen erfolgreichen PostgreSQL-Start zu beschränken. Öffne alte Alben und Assets, führe Suchen aus, lade repräsentative Videos und überprüfe, ob Benutzer und Freigabestatus erwartungsgemäß angezeigt werden.

Führe einen sicheren neuen Schreibvorgang aus, etwa das Hochladen eines entbehrlichen Assets, und bestätige, dass es nach einem normalen Neustart des Dienstes weiterhin zugänglich ist. Beobachte die PostgreSQL- und Immich-Logs auf wiederkehrende Integritäts-, Migrations-, Erweiterungs- oder Berechtigungsfehler, während Lese- und Schreibvorgänge aktiv sind.

Erstelle abschließend mit deiner üblichen Methode ein aktuelles Datenbank-Backup und teste es nach Möglichkeit auf einem isolierten Ziel durch eine Wiederherstellung. Die Entscheidung für Wartung oder Ersatz ist erst abgeschlossen, wenn das aktuelle System nutzbar ist und der nächste Wiederherstellungspunkt nachweislich gesünder ist als der Zustand, der den Vorfall ausgelöst hat.