Immich può utilizzare un database esterno senza compromettere gli aggiornamenti?

Immich può essere indirizzato a un servizio PostgreSQL esterno, ma questo non rende automaticamente sicuri gli aggiornamenti; sposta al di fuori dello stack predefinito la responsabilità relativa alla versione del database, alle estensioni, ai privilegi, ai backup e al rollback.

Considera un database esterno come un confine di compatibilità avanzato, non come una semplice scelta prestazionale. Prima di ogni aggiornamento di Immich o PostgreSQL, verifica i requisiti dell’esatta versione di Immich che prevedi di eseguire, conferma che il server esterno possa fornire le estensioni e i privilegi richiesti, crea un backup ripristinabile e modifica un solo livello di aggiornamento alla volta, così saprai quale componente ha introdotto un problema.

Inizia dal contratto del database esterno

Documenta l’endpoint del database, il nome del database, l’account del servizio, la modalità TLS, la versione principale di PostgreSQL, i nomi e le versioni delle estensioni installate e chi può aggiornarle. Conserva questo registro accanto alla definizione della distribuzione di Immich, in modo che la ricreazione di un container non si riconnetta silenziosamente a un server o a un database diverso.

È possibile utilizzare un server PostgreSQL preesistente, ma non è la configurazione predefinita consigliata per Immich. Per le versioni attuali, il percorso con database indipendente richiede pgvector e VectorChord; Immich è noto per funzionare con PostgreSQL dalla versione 14 alla 19, pgvector >=0.7 e <0.9 e VectorChord >=0.3 e <2.0. Ricontrolla questi intervalli prima di ogni aggiornamento, perché possono cambiare.

Pianifica i privilegi prima del passaggio. In genere Immich richiede un ruolo database con autorizzazione di superutente; eseguirlo senza tale autorizzazione è un percorso avanzato che può richiedere interventi manuali durante gli aggiornamenti, e gli attuali backup automatici del database richiedono i privilegi di superutente. Se il tuo provider esterno non può soddisfare questi requisiti, fermati prima di spostare lo stato di produzione.

Verifica la compatibilità di PostgreSQL e delle estensioni prima di modificare qualsiasi elemento

Elenca le versioni attuali e di destinazione di PostgreSQL insieme a tutte le estensioni da cui dipende Immich. Un aggiornamento della versione principale di PostgreSQL può richiedere file binari delle estensioni compilati per la versione principale di destinazione, mentre un aggiornamento di Immich può richiedere un’estensione più recente o un comportamento di migrazione diverso, anche se PostgreSQL continua ad avviarsi normalmente.

I file dei pacchetti delle estensioni e lo stato SQL delle estensioni devono essere aggiornati deliberatamente insieme al database, invece di presumere che seguano automaticamente un aggiornamento di PostgreSQL. Consulta le dipendenze per l’aggiornamento delle estensioni PostgreSQL prima di modificare la versione principale del database o i pacchetti delle estensioni richiesti da Immich.

Se il provider esterno non ti consente di installare o aggiornare l’estensione richiesta, modificare le impostazioni di precaricamento condivise quando necessario o concedere i privilegi richiesti dalla migrazione, fermati prima di aggiornare Immich. Un database che accetta query ordinarie può comunque non essere adatto alla prossima migrazione dell’applicazione.

Mantieni separati gli aggiornamenti della versione principale del database da quelli di Immich

Evita di combinare un aggiornamento della versione principale di PostgreSQL, un aggiornamento delle estensioni e un aggiornamento dell’applicazione Immich nello stesso intervento di manutenzione, a meno che tu non abbia già provato l’intera sequenza. Quando più confini di compatibilità cambiano contemporaneamente, un avvio non riuscito non indica più quale livello abbia causato il problema.

Gli aggiornamenti minori di PostgreSQL e gli aggiornamenti della versione principale sono interventi di manutenzione diversi, e gli aggiornamenti principali richiedono che l’ambiente di destinazione, comprese le estensioni di terze parti, sia preparato in anticipo. Mantieni gli aggiornamenti della versione principale di PostgreSQL separati da un aggiornamento dell’applicazione Immich ogni volta che è possibile, così un avvio non riuscito lascerà comunque una sola modifica chiara da analizzare.

Su un server domestico, la sequenza con il rischio più basso è solitamente: creare i backup, verificare un ripristino, aggiornare un livello, eseguire la convalida e poi proseguire. Se una versione di Immich richiede una modifica al database, segui l’ordine prescritto per quella versione invece di applicare una procedura generica di aggiornamento di PostgreSQL.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Conserva un percorso di rollback che copra sia il database sia i contenuti multimediali

Un database esterno rende più facile dimenticare che lo stato di Immich è suddiviso tra PostgreSQL e la libreria multimediale. Esegui il backup del database con un metodo coerente con il database e conserva lo stato pertinente di contenuti multimediali e configurazione nella stessa finestra di ripristino, prima di una migrazione che possa modificare gli schemi o i metadati degli elementi.

Lo stato del database, i file dell’applicazione, la configurazione e i caricamenti devono essere coerenti al momento del ripristino. Usa un backup coerente del container del database come modello di accettazione, non limitarti a verificare se PostgreSQL si avvia.

Non considerare pronto il rollback finché non sai cosa accade a entrambi i lati se la migrazione dell’applicazione viene completata solo parzialmente. Conserva la vecchia versione dell’applicazione, la definizione della distribuzione, il backup del database e lo stato dei contenuti multimediali abbastanza a lungo da consentire il ripristino senza sovrascrivere l’unica copia sicuramente funzionante con uno stato più recente.

Convalida l’aggiornamento come applicazione, non solo come connessione al database

Dopo la modifica, verifica che PostgreSQL accetti il ruolo Immich previsto, che le estensioni richieste siano presenti nelle versioni attese e che la migrazione di Immich venga completata senza errori ripetuti del database. Una connessione TCP riuscita o `SELECT 1` dimostra la connettività, non la compatibilità con l’applicazione.

Usa quindi Immich normalmente: carica vecchi album, apri foto e video rappresentativi, esegui ricerche, controlla gli utenti o la condivisione quando pertinente e carica un elemento usa e getta. Durante queste azioni, osserva i log dell’applicazione e del database per individuare estensioni mancanti, errori di autorizzazione, errori di migrazione o tentativi ripetuti.

Solo dopo che l’applicazione ha superato questi controlli dovresti riprendere la normale conservazione dei backup e rimuovere la copia per il rollback. Se il database esterno fa sì che i normali aggiornamenti di Immich dipendano ripetutamente da interventi manuali sulle estensioni o sui privilegi che non puoi provare in modo affidabile, il ciclo di vita predefinito con database dedicato è la scelta operativa più sicura.