Tecken på att en Immich-databas behöver underhåll eller bytas ut

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Signs That an Immich Database Needs Maintenance or Replacement - Zima Store Online

En Immich-databas som bara är långsam kan behöva vanligt PostgreSQL-underhåll eller en resursåtgärd; en databas som uppvisar återkommande integritets- eller återställningsfel kan behöva återställas eller ersättas från en verifierad säkerhetskopia.

Använd inte ”bygg om databasen” som en generell prestandaåtgärd. Separera först normal tillväxt, bloat, inaktuell statistik, blockerat underhåll och lagringslatens från korruption eller ett klustertillstånd som inte går att återställa. Bevara en återställningspunkt innan ingrepp, mät en underhållsändring i taget och gå över till en ren återställning först när bevisen visar att den aktuella databasen inte går att lita på eller reparera på ett säkert sätt.

Skilj prestandaförsämring från integritetsfel

Börja med det exakta symtomet: långsamma sökningar, långsamma tidslinjefrågor, stor databasstorlek, hög diskaktivitet, upprepade PostgreSQL-fel, loopar med kraschåterställning eller en Immich-migrering som inte kan slutföras. Prestandasymtom och integritetssymtom innebär olika risker och bör inte ha samma första reparationsåtgärd.

Bekräfta att värden fortfarande har friskt lagringsutrymme, tillräckligt med ledigt utrymme, normalt minnesbeteende och inget skenande Immich-bakgrundsjobb innan du skyller på PostgreSQL. En överbelastad eller felande disk kan få en frisk databas att verka långsam och kan också orsaka verkliga databasskador om den underliggande lagringen blir opålitlig.

Bevara loggar, databasversion, tilläggsversioner, den senaste uppgraderingshistoriken samt en säkerhetskopia eller ögonblicksbild innan du utför ingripande underhåll. Om den enda databaskopian kan vara korrupt ska du inte köra destruktiv rensning bara för att se om felet försvinner; bevara det underlag som behövs för ett kontrollerat beslut om återställning.

Leta efter underhållssignaler som går att mäta

Vanligt underhåll är en rimlig väg när databasen startar och förblir internt användbar, men frågeprestandan eller diskavtrycket försämras över tid. Användbara belägg är bland annat ökande döda rader, tabeller eller index som växer oproportionerligt, autovacuum som inte hinner med, inaktuell optimeringsstatistik eller långvarigt underhåll som blockeras av andra sessioner.

Döda tupler, bloat, frystryck, blockerad VACUUM och otillräcklig vakuumfrekvens kan alla påverka PostgreSQL:s underhåll och frågeprestanda. Använd VACUUM-signaler på tabellnivå över tid i stället för att anta att en stor databasfil ensam bevisar att databasen behöver ersättas.

Om statistiken pekar på en viss tabell eller ett visst index ska du välja den minst ingripande underhållsåtgärd som stöds för det fyndet och mäta igen. Hoppa inte direkt till VACUUM FULL, omfattande REINDEX-åtgärder eller godtycklig autovacuum-justering i hela klustret; sådana åtgärder kan skapa lås, I/O eller ökat diskbehov och kanske inte åtgärdar den verkliga flaskhalsen.

Bekräfta om bloat eller indextillväxt motsvarar den långsamma vägen

Jämför objekten som ingår i långsamma Immich-operationer med tabell- och indexstorlek, radförändringar och frågebeteende. Bloat spelar roll när det ökar arbetet som krävs för att hitta användbara rader eller gör index mindre effektiva, men databasen kan också vara stor helt enkelt för att biblioteket och metadata är omfattande.

Bloat i tabeller och index bör utvärderas separat, eftersom omfattande bloat kan öka det arbete som krävs för frågor utan att innebära databaskorruption. Använd mätningar av bloat i PostgreSQL för att rikta in dig på ett observerat objekt och uppdatera optimeringsstatistiken där det är lämpligt, i stället för att behandla den totala databasstorleken som diagnosen.

Efter underhållet ska du köra om exakt den Immich-åtgärd som var långsam och jämföra både den upplevda svarstiden och databasens/lagringens beteende. Om operationen inte förbättras ska du, där det är möjligt, återställa den tidigare justeringen och undersöka lagring, frågemönster, bakgrundsjobb eller orsaker på applikationsnivå i stället för att stapla fler databasändringar.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Gå över till återställning eller ersättning när integriteten är osäker

Ersättning är motiverad av belägg för att det aktuella PostgreSQL-tillståndet inte går att lita på eller återställa på ett säkert sätt, inte av ålder i sig. Exempel är upprepad sid- eller kontrollsummekorruption, start- eller återställningsfel som kvarstår på frisk lagring, ett skadat kluster efter en ofullständig lagringsincident eller ett migreringstillstånd som inte kan repareras via den väg som stöds.

Innan du förklarar databasen förlorad ska du bevisa att en känd fungerande säkerhetskopia kan återställas till en ren, kompatibel PostgreSQL-miljö och att Immich kan läsa den. Om den rena återställningen fungerar medan det aktuella klustret upprepar samma integritetsfel har du betydligt starkare grund för att ersätta databasens tillstånd i stället för att fortsätta med reparation på plats.

Reparera lokala, reversibla fel samtidigt som du bevarar osäkra beständiga tillstånd; bygg bara om när återställningskällan är verifierad och målet går att återskapa. Tillämpa samma gräns mellan att reparera och bygga om Immich på databasen. ”Ersättning” ska innebära att kompatibelt PostgreSQL-tillstånd återställs från en känd fungerande källa, inte att du byter databas för att en fråga blev långsam.

Validera databasen genom läs-, skriv- och säkerhetskopieringsåtgärder

Oavsett om du utförde underhåll eller återställde en ren databas ska du validera resultatet genom Immich i stället för att stanna vid en lyckad PostgreSQL-start. Öppna gamla album och objekt, kör sökningar, läs in representativa videor och kontrollera att användare och delningsstatus visas som förväntat.

Gör en säker ny skrivning, till exempel genom att ladda upp ett testobjekt som kan tas bort, och bekräfta att det fortfarande är åtkomligt efter en normal omstart av tjänsten. Övervaka PostgreSQL- och Immich-loggarna efter återkommande integritets-, migrerings-, tilläggs- eller behörighetsfel medan läs- och skrivvägarna är aktiva.

Skapa slutligen en färsk databassäkerhetskopia med din vanliga metod och återställningstesta den på ett isolerat mål när det är praktiskt möjligt. Beslutet om underhåll eller ersättning är slutfört först när det aktuella systemet är användbart och nästa återställningspunkt bevisligen är friskare än det tillstånd som utlöste incidenten.