Quindi da qualche parte hai cambiato la porta di postgres a 50432 invece di 5432? (OPPURE forse il codice di migrazione fa questo e non l’ho mai notato).
Forse dovresti passare al template postgres13 come suggerito nel post originale? E se funziona, quello che farei è spostarmi su un nuovo server ed evitare l’intero problema della transizione alla nuova versione di postgres e semplicemente ripristinare il database sul nuovo server.
Non ho abbastanza spazio per eseguire questo aggiornamento sulla mia partizione Discourse. Tuttavia, ho molto spazio su un altro disco. C’è un modo per usarlo per l’archiviazione temporanea?
Probabilmente è comunque ora di aggiornare il sistema operativo, e passare a una VM pulita è molto più semplice, richiede poco tempo di inattività e, se qualcosa va storto, hai ancora un server funzionante.
Se hai un container dati separato, puoi provare a spostare tutto /var/discourse/shared/data sull’altra partizione e ad adattare i volumi nel tuo YML di conseguenza.
E se non hai un container separato, puoi fare qualcosa del genere, è solo più complicato.
Ho un problema simile (uguale?). Hai controllato il log menzionato?
Nel mio caso: Durante l’aggiornamento, ho prima riscontrato un problema per cui il container dell’app (nel mio caso solo web) non veniva ricompilato perché avevo aggiunto rss-polling come plugin personalizzato e questo sembrava scontrarsi con i nuovi default. Dopo averlo rimosso ha funzionato.
Ma poi ha avuto problemi con la mancanza dell’estensione vettoriale. Questo perché non avevo ricompilato il container dei dati da un po’ di tempo. Sono riuscito a farlo fino alla versione 13, ma ora sono bloccato con la 13 in esecuzione, quando modifico il mio data.yaml in postgres.template o postgres.15.template la migrazione fallisce.
Prima falliva con “spegnimento non pulito” e con i suggerimenti sopra sono riuscito a risolverlo. Ma ora la migrazione fallisce, poiché sembra mancare l’installazione della versione 13? Forse questo è correlato ad alcuni residui nella directory /shared? (Ho già provato a pulire la directory postgres_new).
-----------------------------------------------------------------
pg_upgrade eseguito venerdì 17 ottobre 09:54:37 2025
-----------------------------------------------------------------
comando: "/usr/lib/postgresql/13/bin/pg_ctl" -w -l "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" -D "/shared/postgres_data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" 2>&1
in attesa dell'avvio del server....2025-10-17 09:54:37.744 UTC [1900] LOG: avvio di PostgreSQL 13.22 (Debian 13.22-1.pgdg12+1) su x86_64-pc-linux-gnu, compilato da gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit
2025-10-17 09:54:37.749 UTC [1900] LOG: in ascolto sul socket Unix "/var/lib/postgresql/.s.PGSQL.50432"
2025-10-17 09:54:37.760 UTC [1900] LOG: impossibile aprire il file di configurazione "/etc/postgresql/13/main/pg_hba.conf": File o directory non esistente
2025-10-17 09:54:37.760 UTC [1900] FATAL: impossibile caricare pg_hba.conf
2025-10-17 09:54:37.762 UTC [1900] LOG: il sistema di database è spento
fermato in attesa
pg_ctl: impossibile avviare il server
Esaminare l'output del log.
Quello che probabilmente farei è tornare a PG13 con il vecchio container (se riesci a capirlo), quindi fare un backup e spostarlo su un nuovo server (probabilmente ti serve comunque un nuovo sistema operativo).
Sembra che il container che hai sia in uno stato rotto. Stai cercando di ricostruire con il template PG13? Potrebbe essere necessario spostare la cartella di backup di postgres in postgres_data e tornare alla 13 per far ripartire le cose.
Sì, attualmente funziono con il container PG13. L’ho ricostruito più volte. Ho anche pulito la directory dangling _new. Semplicemente, ogni volta che provo ad andare alla versione 15 o al template ufficiale non versionato, fallisce. Lo migrerò manualmente presto se questo non si risolve da solo. Non vedo come il sistema operativo sia rilevante qui.
Ristrutturerei il tuo volume Mount in modo che l’intera directory Shared o shared/postgres si trovi sullo stesso volume, quindi le rinomine delle directory (che sono regolarmente necessarie) non saranno più un problema.
Potrebbe non essere correlato al problema immediato. Spesso accade che se si utilizza Discourse abbastanza a lungo da necessitare di un aggiornamento di PostgreSQL, è probabile che sia necessario anche un aggiornamento del sistema operativo.
Passare a un nuovo server consente di spostarsi con tempi di inattività praticamente nulli e senza il rischio di ritrovarsi in uno stato di malfunzionamento.
D’altra parte, la maggior parte degli aggiornamenti che ho eseguito con il mio script (che fa semplicemente ciò che è descritto qui) sono andati a buon fine.
Penso che dovresti passare a quello non versionato, quindi eseguire le due ricostruzioni.
