Segnali che indicano che un database Immich necessita di manutenzione o sostituzione
Un database Immich semplicemente lento può richiedere la normale manutenzione di PostgreSQL o una correzione delle risorse; un database che mostra ripetuti errori di integrità o di ripristino può richiedere il ripristino o la sostituzione a partire da un backup verificato.
Non usare “ricostruire il database” come soluzione generica ai problemi di prestazioni. Distingui innanzitutto la crescita normale, il bloat, le statistiche obsolete, la manutenzione bloccata e la latenza dello storage dalla corruzione o da uno stato del cluster irrecuperabile. Conserva un punto di ripristino prima di eseguire operazioni invasive, misura una modifica di manutenzione alla volta e passa a un ripristino pulito solo quando le prove indicano che non ci si può fidare del database attuale o che non è possibile ripararlo in sicurezza.
Distinguere il deterioramento delle prestazioni dai problemi di integrità
Inizia dal sintomo esatto: ricerche lente, query lente sulla timeline, dimensioni elevate del database, intensa attività del disco, errori PostgreSQL ripetuti, cicli di ripristino dopo un arresto anomalo o una migrazione di Immich che non riesce a completarsi. I sintomi legati alle prestazioni e quelli legati all’integrità comportano rischi diversi e non dovrebbero avere la stessa prima procedura di riparazione.
Verifica che l’host disponga ancora di uno storage integro, spazio libero sufficiente, un normale utilizzo della memoria e nessun processo in background di Immich fuori controllo prima di attribuire la colpa a PostgreSQL. Un disco saturo o in fase di guasto può far sembrare lento un database integro e può anche causare danni reali al database se lo storage sottostante diventa inaffidabile.
Conserva i log, la versione del database, le versioni delle estensioni, la cronologia degli aggiornamenti recenti e un backup o uno snapshot prima di eseguire la manutenzione invasiva. Se l’unica copia del database potrebbe essere corrotta, non eseguire una pulizia distruttiva solo per vedere se l’errore scompare; conserva le prove necessarie per decidere se procedere a un ripristino controllato.
Cercare segnali di manutenzione misurabili
La manutenzione ordinaria diventa un’opzione plausibile quando il database si avvia e rimane utilizzabile internamente, ma le prestazioni delle query o l’occupazione del disco peggiorano nel tempo. Tra gli elementi utili rientrano l’aumento delle righe morte, tabelle o indici che crescono in modo sproporzionato, autovacuum che non riesce a tenere il passo, statistiche obsolete del pianificatore o attività di manutenzione di lunga durata bloccate da altre sessioni.
Le tuple morte, il bloat, la pressione del freezing, VACUUM bloccato e una frequenza insufficiente di vacuum possono influire sulla manutenzione e sulle prestazioni delle query di PostgreSQL. Usa i segnali VACUUM a livello di tabella nel tempo invece di presumere che un file di database di grandi dimensioni dimostri da solo che il database debba essere sostituito.
Se le statistiche indicano una singola tabella o un singolo indice, scegli l’azione di manutenzione supportata meno invasiva per quel dato riscontro e misura nuovamente. Evita di passare subito a VACUUM FULL, a operazioni REINDEX estese o a regolazioni arbitrarie di autovacuum sull’intero cluster; queste azioni possono creare lock, I/O o un’ulteriore richiesta di spazio su disco e potrebbero non risolvere il vero collo di bottiglia.
Verificare se il bloat o la crescita degli indici corrispondono al percorso lento
Confronta gli oggetti coinvolti nelle operazioni lente di Immich con le dimensioni di tabelle e indici, il ricambio delle righe e il comportamento delle query. Il bloat è rilevante quando aumenta il lavoro necessario per trovare righe utili o rende meno efficaci gli indici, ma il database può essere grande anche semplicemente perché grandi sono la libreria e i relativi metadati.
Il bloat di tabelle e indici deve essere valutato separatamente, perché un bloat eccessivo può aumentare il lavoro richiesto dalle query senza implicare una corruzione del database. Usa controlli misurati del bloat di PostgreSQL per intervenire su un oggetto osservato e aggiorna le statistiche del pianificatore quando opportuno, invece di considerare le dimensioni totali del database come una diagnosi.
Dopo la manutenzione, ripeti esattamente l’operazione di Immich che risultava lenta e confronta sia la latenza percepita dall’utente sia il comportamento del database e dello storage. Se l’operazione non migliora, ripristina quando possibile le regolazioni precedenti e analizza lo storage, i modelli delle query, i processi in background o le cause a livello applicativo invece di aggiungere altre modifiche al database.
Passare al ripristino o alla sostituzione quando l’integrità è incerta
La sostituzione è giustificata da prove che indicano che lo stato attuale di PostgreSQL non è affidabile o non può essere recuperato in sicurezza, non dalla sua sola anzianità. Tra gli esempi rientrano corruzione ripetibile di pagine o checksum, errori persistenti all’avvio o durante il ripristino su uno storage integro, un cluster danneggiato dopo un problema di storage incompleto o uno stato di migrazione che non può essere corretto seguendo il percorso supportato.
Prima di dichiarare perso il database, dimostra che un backup noto come integro può essere ripristinato in un ambiente PostgreSQL pulito e compatibile e che Immich può leggerlo. Se il ripristino pulito funziona mentre il cluster attuale ripete lo stesso errore di integrità, hai basi molto più solide per sostituire lo stato del database invece di continuare con la riparazione sul posto.
Ripara i problemi localizzati e reversibili preservando lo stato persistente incerto; ricostruisci solo quando la fonte di ripristino è verificata e la destinazione è riproducibile. Applica lo stesso confine tra riparazione e ricostruzione di Immich anche al database. Per “sostituzione” si deve intendere il ripristino di uno stato PostgreSQL compatibile da una fonte nota come integra, non il passaggio a un altro database perché una query è diventata lenta.
Convalidare il database tramite operazioni di lettura, scrittura e backup
Sia che tu abbia eseguito la manutenzione sia che tu abbia ripristinato un database pulito, convalida il risultato tramite Immich invece di fermarti a un avvio riuscito di PostgreSQL. Apri album e risorse meno recenti, esegui ricerche, carica video rappresentativi e verifica che utenti e impostazioni di condivisione siano visualizzati come previsto.
Esegui una nuova scrittura sicura, ad esempio caricando una risorsa usa e getta, e verifica che rimanga accessibile dopo un normale riavvio del servizio. Controlla i log di PostgreSQL e Immich alla ricerca di errori ricorrenti di integrità, migrazione, estensioni o autorizzazioni mentre i percorsi di lettura e scrittura sono attivi.
Infine, crea un nuovo backup del database utilizzando il metodo abituale e, quando possibile, testane il ripristino su una destinazione isolata. La decisione di manutenzione o sostituzione è completa solo quando il sistema attuale è utilizzabile e il successivo punto di ripristino è dimostrabilmente più integro dello stato che ha causato l’incidente.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...
Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...
Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...
