ATTENZIONE! L’aggiornamento richiede molto spazio libero su disco (2 volte la dimensione del database).
Abbiamo appena rilasciato le modifiche per aggiornare la nostra immagine Docker a PostgreSQL 18. Tutti gli amministratori di siti che ricostruiscono Discourse da riga di comando verranno aggiornati da PostgreSQL 15 a PostgreSQL 18. Nota: se hai evitato l’aggiornamento quando è stato rilasciato PostgreSQL 15 nel 2025, puoi saltare quell’aggiornamento e passare direttamente a PostgreSQL 18.
Se in precedenza avevi bloccato l’aggiornamento, cambia il template di PostgreSQL in app.yml da templates/postgres.13.template.yml a templates/postgres.template.yml.
Come per qualsiasi aggiornamento, è fortemente consigliato effettuare un backup prima di procedere.
Modifiche alla localizzazione
In passato abbiamo riscontrato corruzione degli indici quando glibc veniva aggiornata, ad esempio durante gli aggiornamenti del sistema operativo. A partire da PostgreSQL 17 è disponibile un nuovo fornitore di localizzazione integrato che è disaccoppiato dalla glibc del sistema operativo e quindi stabile tra le diverse versioni. Come parte di questo aggiornamento, stiamo passando a questo fornitore integrato utilizzando la localizzazione C.UTF-8. Questa localizzazione utilizza l’ordinamento dei punti di codice e la raccomandiamo per i motivi di stabilità sopra menzionati.
Per realizzare il cambio di localizzazione, dobbiamo prima creare il nuovo cluster del database utilizzando il fornitore di localizzazione integrato e successivamente eseguire il dump e il restore del database in questo cluster. Per questo motivo, i requisiti di spazio su disco sono maggiori rispetto agli aggiornamenti precedenti, in cui eseguivamo aggiornamenti in-place.
Aggiornamento
Guida di installazione ufficiale (contenitore singolo)
Durante la prossima ricostruzione, vedrai questo messaggio alla fine:
-------------------------------------------------------------------------------------
AGGIORNAMENTO DI POSTGRES COMPLETATO
Il vecchio database 15 è memorizzato in /shared/postgres_data_old
Per completare l'aggiornamento, esegui di nuovo la ricostruzione con:
./launcher rebuild app
-------------------------------------------------------------------------------------
Questo significa che l’aggiornamento è andato a buon fine! Devi solo eseguire una nuova ricostruzione per riavviare il tuo sito.
Installazione con contenitore dati
Se stai utilizzando una configurazione con un contenitore dati dedicato basato sull’esempio fornito nel nostro repository discourse_docker, devi assicurarti di arrestare PostgreSQL in modo sicuro e pulito.
Al giorno d’oggi, abbiamo job in background che eseguono query che durano diversi minuti, quindi arrestare il contenitore web aiuterà ad arrestare il contenitore dati in modo sicuro.
./launcher stop web_only
./launcher stop data
./launcher rebuild data
./launcher rebuild data
./launcher rebuild web_only
Prima di eseguire la prima ricostruzione del contenitore dati, puoi monitorare il log di PostgreSQL per verificare se è stato arrestato correttamente.
Eseguendo tail -f shared/standalone/log/var-log/postgres/current dovresti ottenere il seguente log se l’arresto è stato pulito:
2025-01-24 09:19:06.437 UTC [37] LOG: received smart shutdown request
2025-01-24 09:19:06.444 UTC [37] LOG: background worker "logical replication launcher" (PID 54) exited with exit code 1
2025-01-24 09:19:06.446 UTC [49] LOG: shutting down
2025-01-24 09:19:06.468 UTC [37] LOG: database system is shut down
Posticipare l’aggiornamento
Se hai bisogno di posticipare l’aggiornamento durante la prossima ricostruzione, puoi sostituire il template di PostgreSQL nel file app.yml cambiando "templates/postgres.template.yml" in "templates/postgres.15.template.yml".
Questo non è consigliato, poiché alcuni amministratori di siti potrebbero dimenticare di revertire la modifica successivamente.
Compiti opzionali post-aggiornamento
Ottimizzazione delle statistiche di PostgreSQL
Dopo l’aggiornamento, il nuovo PostgreSQL non avrà statistiche delle tabelle disponibili. Puoi generarle utilizzando:
docker exec -u postgres app \
/usr/lib/postgresql/18/bin/vacuumdb -d discourse --analyze-in-stages
Pulizia dei vecchi dati
Per un’installazione standard, puoi eliminare i vecchi dati in formato PG15 con il seguente comando:
cd /var/discourse
./launcher cleanup
Se hai un contenitore dati separato, dovrai rimuovere la copia di backup in questo modo:
rm -fr /var/discourse/shared/data/postgres_data_old/
FAQ
Il cluster di origine non è stato arrestato in modo pulito
Se ricevi un errore di aggiornamento con il messaggio sopra, puoi provare un approccio più semplice per riportarlo in uno stato migliore.
Riavvia il vecchio contenitore con ./launcher start app. Attendi alcuni minuti finché non è tornato online.
Ora arrestalo di nuovo con ./launcher stop app. Dopo di che, monitora i log per verificare se è stato un arresto pulito:
tail -f shared/standalone/log/var-log/postgres/current
2025-01-24 09:19:06.437 UTC [37] LOG: received smart shutdown request
2025-01-24 09:19:06.444 UTC [37] LOG: background worker "logical replication launcher" (PID 54) exited with exit code 1
2025-01-24 09:19:06.446 UTC [49] LOG: shutting down
2025-01-24 09:19:06.468 UTC [37] LOG: database system is shut down
Se i log non indicano che il database è stato arrestato, puoi riavviare di nuovo il vecchio contenitore, entrare con ./launcher enter app, eseguire questi comandi e monitorare di nuovo i log una volta terminato.
export SVWAIT=300
sv stop nginx
sv stop unicorn
sv stop postgres
exit
Se i log sembrano quelli sopra, ora puoi provare di nuovo a eseguire l’aggiornamento con ./launcher rebuild app.
I valori lc_collate per il database “postgres” non corrispondono
Questo errore si verifica se stai utilizzando localizzazioni non predefinite per il tuo database. È stato segnalato che sono necessarie 3 variabili per il successo. Assicurati che la sezione env: del tuo file app.yml contenga le 3 righe:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
Modificando en_US.UTF-8 con la tua localizzazione.
Ogni ricostruzione esegue di nuovo l’aggiornamento, ovvero loop di aggiornamento
Quando ciò accade, i tuoi log di aggiornamento conterranno
mv: cannot move '/shared/postgres_data' to '/shared/postgres_data_old/postgres_data': Directory not empty
mv: cannot move '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new': Directory not empty
Questo significa che ci sono ancora file dell’ultimo aggiornamento rimasti. Spostali altrove prima di continuare.
Ho saltato l’aggiornamento a PostgreSQL 15, cosa fare ora?
Puoi seguire le istruzioni standard all’inizio di questa guida e esse aggiorneranno dalla tua versione a 18 senza problemi.
