Signalen dat een Immich-database onderhoud of vervanging nodig heeft

Een Immich-database die alleen traag is, heeft mogelijk regulier PostgreSQL-onderhoud of een oplossing voor een tekort aan resources nodig; een database die herhaaldelijk integriteits- of herstelfouten vertoont, moet mogelijk worden teruggezet of vervangen vanuit een geverifieerde back-up.

Gebruik ‘de database opnieuw opbouwen’ niet als algemene oplossing voor prestatieproblemen. Maak eerst onderscheid tussen normale groei, bloat, verouderde statistieken, geblokkeerd onderhoud en opslaglatentie enerzijds, en corruptie of een onherstelbare clusterstatus anderzijds. Zorg vóór ingrijpende werkzaamheden voor een herstelpunt, meet telkens één onderhoudswijziging en ga alleen over op een schone herstelbewerking wanneer het bewijs erop wijst dat de huidige database niet kan worden vertrouwd of veilig kan worden gerepareerd.

Maak onderscheid tussen prestatieverlies en integriteitsproblemen

Begin met het exacte symptoom: trage zoekopdrachten, trage tijdlijnquery’s, een grote database, hoge schijfactiviteit, herhaalde PostgreSQL-fouten, lussen tijdens crash recovery of een Immich-migratie die niet kan worden voltooid. Prestatie- en integriteitssymptomen brengen verschillende risico’s met zich mee en vereisen niet dezelfde eerste reparatie.

Controleer of de host nog over gezonde opslag en voldoende vrije ruimte beschikt, of het geheugengedrag normaal is en of er geen op hol geslagen Immich-achtergrondtaak actief is voordat je PostgreSQL de schuld geeft. Een overbelaste of defecte schijf kan een gezonde database traag laten lijken en kan ook echte databaseschade veroorzaken als de onderliggende opslag onbetrouwbaar wordt.

Bewaar logboeken, databaseversie, extensieversies, recente upgradegeschiedenis en een back-up of snapshot voordat je ingrijpend onderhoud uitvoert. Als de enige databasekopie mogelijk corrupt is, voer dan geen destructieve opschoning uit alleen om te zien of de fout verdwijnt; bewaar het bewijs dat nodig is om gecontroleerd te beslissen over herstel.

Zoek naar meetbare signalen voor onderhoud

Regulier onderhoud wordt aannemelijk wanneer de database opstart en intern bruikbaar blijft, maar queryprestaties of schijfruimtegebruik na verloop van tijd verslechteren. Nuttig bewijs omvat een toenemend aantal dode rijen, tabellen of indexen die buitenproportioneel groeien, autovacuum dat niet kan bijhouden, verouderde plannerstatistieken of langdurig onderhoud dat door andere sessies wordt geblokkeerd.

Dode tuples, bloat, druk door transacties die moeten worden bevroren, geblokkeerde VACUUM-bewerkingen en een onvoldoende hoge vacuümfrequentie kunnen allemaal van invloed zijn op PostgreSQL-onderhoud en queryprestaties. Gebruik VACUUM-signalen op tabelniveau over een langere periode in plaats van aan te nemen dat alleen een groot databasebestand bewijst dat de database moet worden vervangen.

Als de statistieken naar één tabel of index wijzen, kies dan voor die bevinding de minst ingrijpende ondersteunde onderhoudsactie en meet opnieuw. Spring niet direct naar VACUUM FULL, brede REINDEX-bewerkingen of willekeurige autovacuum-aanpassingen voor de hele cluster; dergelijke acties kunnen locks, I/O of extra schijfruimte vereisen en lossen mogelijk niet de echte bottleneck op.

Bevestig of bloat of indexgroei overeenkomt met het trage pad

Vergelijk de objecten die betrokken zijn bij trage Immich-bewerkingen met tabel- en indexgrootte, wijzigingen in het aantal rijen en querygedrag. Bloat is relevant wanneer hierdoor meer werk nodig is om bruikbare rijen te vinden of indexen minder effectief worden, maar de database kan ook gewoon groot zijn omdat de bibliotheek en metadata omvangrijk zijn.

Tabel- en index-bloat moeten afzonderlijk worden beoordeeld, omdat overmatige bloat de benodigde query-inspanning kan vergroten zonder dat dit op corruptie van de database wijst. Gebruik gemeten controles op PostgreSQL-bloat om een vastgesteld object gericht te onderzoeken en werk de plannerstatistieken waar nodig bij, in plaats van de totale databasegrootte als diagnose te beschouwen.

Voer na het onderhoud opnieuw exact de Immich-actie uit die traag was en vergelijk zowel de voor de gebruiker merkbare latentie als het gedrag van de database en opslag. Als de bewerking niet verbetert, draai de eerdere tuning waar mogelijk terug en onderzoek opslag, querypatronen, achtergrondtaken of oorzaken op applicatieniveau in plaats van steeds meer databasewijzigingen op elkaar te stapelen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Schaal op naar herstel of vervanging wanneer de integriteit onzeker is

Vervanging is gerechtvaardigd door bewijs dat de huidige PostgreSQL-status niet kan worden vertrouwd of veilig kan worden hersteld, niet alleen door ouderdom. Voorbeelden zijn herhaalbare paginacorruptie of checksumfouten, opstart- of herstelfouten die op gezonde opslag aanhouden, een beschadigde cluster na een onvolledig opslagincident of een migratiestatus die niet via het ondersteunde pad kan worden gerepareerd.

Voordat je de database verloren verklaart, moet je aantonen dat een bekende goede back-up kan worden teruggezet in een schone, compatibele PostgreSQL-omgeving en dat Immich deze kan lezen. Als het schone herstel wel werkt terwijl de huidige cluster dezelfde integriteitsfout blijft vertonen, heb je een veel sterkere basis om de databasestatus te vervangen in plaats van door te gaan met reparaties op de bestaande installatie.

Repareer lokale, omkeerbare fouten terwijl je onzekere persistente status behoudt; bouw de database alleen opnieuw op wanneer de herstelbron is geverifieerd en het doel reproduceerbaar is. Pas die grens tussen Immich repareren en opnieuw opbouwen ook op de database toe. ‘Vervanging’ moet betekenen dat je compatibele PostgreSQL-status herstelt vanuit een bekende goede bron, niet dat je van database wisselt omdat een query traag is geworden.

Valideer de database via lees-, schrijf- en back-upbewerkingen

Of je nu onderhoud hebt uitgevoerd of een schone database hebt teruggezet, valideer het resultaat via Immich in plaats van te stoppen bij een geslaagde PostgreSQL-start. Open oude albums en assets, voer zoekopdrachten uit, laad representatieve video’s en controleer of gebruikers en deelstatus naar verwachting worden weergegeven.

Voer één veilige nieuwe schrijfbewerking uit, zoals het uploaden van een wegwerpasset, en controleer of deze na een normale herstart van de service toegankelijk blijft. Houd de PostgreSQL- en Immich-logboeken in de gaten voor terugkerende integriteits-, migratie-, extensie- of rechtenfouten terwijl de lees- en schrijfpaden actief zijn.

Maak ten slotte een nieuwe databaseback-up volgens je gebruikelijke methode en test die waar praktisch op een geïsoleerd doel terug te zetten. De beslissing over onderhoud of vervanging is pas afgerond wanneer het huidige systeem bruikbaar is en het volgende herstelpunt aantoonbaar gezonder is dan de status die het incident veroorzaakte.