Ottima idea, grazie Ed! Ho aggiornato il mio post. 
2 Mi Piace
Con questa modifica, ho riscontrato una riduzione complessiva dell’utilizzo della memoria di circa il 4%. Ottimo lavoro.
2 Mi Piace
Grazie Lilly, ho eseguito l’aggiornamento in precedenza e sembra che tutto sia andato bene 
1 Mi Piace
Non è raro che le tabelle e gli indici riscritti siano molto più compatti.
1 Mi Piace
Uh, è nel rumore di fondo del funzionamento di Postgres (a seconda che si guardi prima o dopo vacuum, rebuild della tabella, ecc.)
Da allora non ho notato nulla di mancante, quindi, per quanto ne so, tutto è a posto.
1 Mi Piace
Sto eseguendo Discourse in un contenitore Docker standalone su /var/discourse.
Ho tentato di aggiornare il database PostgreSQL incorporato dalla versione 15 alla versione 18. L’aggiornamento sembrava completato e la directory dei dati attiva ora riporta:
/shared/postgres_data/PG_VERSION
18
Tuttavia, il contenitore Discourse ricostruito contiene ancora solo i binari di PostgreSQL 15:
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
Il servizio PostgreSQL è configurato per eseguire:
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
mentre la directory dati effettiva di Discourse è montata su:
/shared/postgres_data
Di conseguenza, PostgreSQL fallisce con:
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).
Comprendo che le immagini Docker recenti di Discourse dovrebbero includere i binari di PostgreSQL 18. Ho modificato app.yml per utilizzare il template di PostgreSQL 18 e ho ricostruito l’app, ma il contenitore risultante ha ancora i binari di PostgreSQL 15 e lo script del servizio punta ancora a /etc/postgresql/15/main.
La parte rilevante della mia attuale configurazione del servizio è:
HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
Le mie domande sono:
-
Qual è il modo corretto per ricostruire o aggiornare il contenitore Discourse in modo che contenga effettivamente i binari di PostgreSQL 18?
-
Esiste un template o un tag di immagine specifico che dovrebbe essere utilizzato in
app.yml? -
Una volta disponibile PostgreSQL 18, qual è la procedura supportata per avviarlo contro la directory esistente
/shared/postgres_data?
Non ho eliminato né reinizializzato la directory dei dati di PostgreSQL 18. Preferirei recuperare il cluster aggiornato piuttosto che ripristinare i vecchi dati di PostgreSQL 15.
1 Mi Piace
in base alle istruzioni nell’OP, quel passo sembra non essere stato necessario, a meno che non stia perdendo qualcosa?
Semplicemente ricostruendo un’installazione standard, avrebbe dovuto scaricare l’immagine più recente e avviare la migrazione.
A meno che tu non stia in qualche modo optando per non usare l’immagine più recente, i nuovi binari erano sicuramente garantiti? Molto strano …
Sei sicuro di non aver fissato una versione dell’immagine?
3 Mi Piace
Non intenzionalmente? Sto usando il repository git e il branch regolari e non c’è nulla nel mio app.yml che mi indichi di aver fissato qualcosa. Ho cambiato solo il template di postgres 18 per vedere se aiutasse; sì, quello è stato un passaggio non necessario che non ha aiutato, quindi posso riportarlo come prima.
Qualche suggerimento su come ottenere i nuovi binari? Non ci sono proprio, nonostante quante volte li ricostruisca:
root@hostname-app:/usr/lib/postgresql# ls -la
total 12
drwxr-xr-x 1 root root 4096 May 21 00:47 .
drwxr-xr-x 1 root root 4096 May 21 00:48 ..
drwxr-xr-x 1 root root 4096 May 21 00:47 15
root@hostname-app:/usr/lib/postgresql#
1 Mi Piace
Per risparmiarti tempo e seccature, ti consiglio di usare il tuo ultimo backup per creare un nuovo server: ti risparmierà molto lavoro.
1 Mi Piace
Va bene, suppongo di sì! A volte non vale la pena perdere tempo a sistemare le cose. Grazie.
2 Mi Piace
Quando non riesci ad accedere al pannello di amministrazione perché la tua istanza di Discourse ha deciso di impazzire, come puoi ottenere il database tramite root@ per caricarlo su una nuova istanza? (magari una guida separata)
Oppure qual è il comando da riga di comando per eseguire la stessa operazione che si farebbe tramite il pannello di amministrazione?
Ok, e più nel merito, devo ricostruire l’app per risolvere un errore di certificato che sembra essere apparso all’improvviso (nessuna modifica ha preceduto l’apparente fallimento) - sta comparando l’errore “porta 443 non accessibile” (la procedura guidata indica: “Verifica DNS non riuscita”) - non so se CF o DO abbiano cambiato qualcosa, ma di nuovo non ho modificato nulla sul mio lato - beh, non riesco a ricostruire a causa forse di questi due errori, incluso quello qui sotto, a differenza dell’ultima volta che era un errore di spazio insufficiente, hai un’idea di come superare questo errore qui sotto?
Da aggiungere, ho ricevuto anche questo esatto stesso errore prima e dopo aver aumentato la dimensione del disco primario (per far fronte ai requisiti di postgres 15 > 18)
FAILED
--------------------
Pups::ExecError: if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #<Process::Status: pid 17 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
Ah, ok, ho trovato quello che credo mi servisse, pubblicato da @Lilly molto tempo fa in questo topic.
cd /var/discourse
./launcher enter web_only
discourse backup
exit
Da questo deduco che posso generare un backup del db utilizzabile che posso caricare su un’istanza discourse nuova, aggirando tutti i problemi.
Quel comando fornisce un backup completo, cioè post + upload/immagini?
Consiglio un backup solo del database e l’uso di rsync per spostare tutto il resto. Sposta un sito Discourse su un altro VPS con rsync. Puoi anche usare rsync per trasferire i certificati SSL in modo da poter portare online il nuovo sito prima di modificare il DNS.
Ecco come lo faccio io: Changing Digital Ocean droplets with doctl (resize, floating ip, rename, etc) - Howto - Literate Computing Dashboard
MODIFICA: Mi dispiace. Non riesco a capire se hai risolto il tuo problema o no. Se ho capito bene, la cosa più semplice da fare è tornare al template predefinito, senza versione, e ricostruire di nuovo.
2 Mi Piace
Hai ricostruito due volte il contenitore dei dati (probabilmente quello dell’app nel tuo caso), come richiesto?
(Per inciso, il messaggio di aggiornamento indica di ricostruire l’app, ma immagino che intendesse “il contenitore del database, che potrebbe essere chiamato app o data” oppure si riferisce a entrambi?)
E un po’ di feedback: un po’ di tempo fa ho provato a passare dalla versione 13 alla 15, ma è fallito più volte e sono rimasto con il template .13. Ora che è stata offerta la versione .18, ho riprovato e ha funzionato senza problemi (dovevo solo ripulire le directory _new e _older prima). Quindi ora posso di nuovo usare il template dati predefinito senza versione. Ottimo lavoro nel rendere l’aggiornamento così robusto.
1 Mi Piace
Ho appena notato nel log degli errori che, prima dell’aggiornamento di PG, sembrava ci fossero alcuni errori relativi a SQL nei log:
Job exception: PG::UndefinedFunction: ERROR: function array_remove(bigint[], integer) does not exist LINE 1: ...ATE "access_control_lists" SET allowed_user_ids = array_remo...
È strano, sembra che questa funzione provenga da PG9, mentre prima stavo usando la versione 15. Potrebbe trattarsi di un problema di permessi o di search path? Sembra che non si verifichi più dopo l’aggiornamento del DB, ma forse è una questione di tempistica dei batch… Vedo che la funzione viene utilizzata in diversi punti, persino negli script di migrazione.
Forse significa che alcune funzioni falliscono nelle versioni più vecchie di PostgreSQL, nonostante i relativi template siano ancora elencati. Magari l’ho trascurato, ma pensavo che le versioni più vecchie fossero compatibili.
1 Mi Piace