Aggiornamento PostgreSQL 12

:warning: ATTENZIONE! Se il tuo database è molto grande, avrai bisogno di molto spazio su disco aggiuntivo (2 volte la dimensione del database) e dovresti prestare molta attenzione con questo aggiornamento!

Abbiamo appena implementato il tanto atteso aggiornamento della versione principale di PostgreSQL. Qualsiasi amministratore di sito che ricostruisce Discourse da riga di comando verrà aggiornato a PostgreSQL 12 dalla vecchia versione PostgreSQL 10.

Stiamo eseguendo questa nuova versione da un po’ di tempo su Meta e tutto funziona correttamente. PostgreSQL 12 apporta numerosi miglioramenti che verranno sfruttati automaticamente da Discourse.

Aggiornamento

Guida all’installazione ufficiale (singolo contenitore)

Al prossimo rebuild, vedrai questo messaggio alla fine:

Aggiornamento completato
----------------

Per completare l'aggiornamento, esegui nuovamente il rebuild utilizzando:

./launcher rebuild app
-------------------------------------------------------------------------------------

Ciò significa che tutto è andato bene durante l’aggiornamento! Devi solo eseguire un nuovo rebuild per riportare il tuo sito online.

Installazione con contenitore dati dedicato

Se stai utilizzando una configurazione con un contenitore dati dedicato basato sul campione fornito nel nostro repository discourse_docker, assicurati di arrestare PostgreSQL in modo sicuro e pulito.

Oggi abbiamo processi in background che eseguono query che durano diversi minuti, quindi arrestare il contenitore web aiuterà a chiudere 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 il primo rebuild sul contenitore dati, puoi seguire il log di PostgreSQL per verificare se è stato arrestato correttamente.

Eseguire tail -f shared/data/log/var-log/postgres/current dovrebbe mostrare il seguente log se l’arresto è stato pulito:

2020-05-13 18:33:33.457 UTC [36] LOG:  received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG:  worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG:  shutting down
2020-05-13 18:33:33.479 UTC [36] LOG:  database system is shut down

Esecuzione di un aggiornamento manuale / ambienti con spazio limitato

:warning::warning::warning:
DEVI EFFETTUARE UN BACKUP DEI DATI POSTGRES PRIMA DI PROVARE QUESTO
:warning::warning::warning:

Se ti trovi in un ambiente con spazio limitato e non hai modo di ottenere più spazio, puoi provare quanto segue:

./launcher stop app #(o entrambi web_only e data se è il tuo caso)
mkdir -p /var/discourse/shared/standalone/postgres_data_new
docker run --rm \
	-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/10/data \
	-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/12/data \
	tianon/postgres-upgrade:10-to-12
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
./launcher rebuild app #(o prima data e poi web_only se è il tuo caso)

Nei miei test, questa procedura richiede meno di 1x la dimensione attuale del tuo database in spazio libero.

Posticipare l’aggiornamento

Se devi posticipare l’aggiornamento durante il prossimo rebuild, puoi sostituire il template di PostgreSQL nel tuo file app.yml modificando \"templates/postgres.template.yml\" in \"templates/postgres.10.template.yml\".

Questo non è raccomandato, poiché alcuni amministratori di sito potrebbero dimenticare di ripristinare la modifica in seguito.

Attività opzionali post-aggiornamento

Ottimizzazione delle statistiche di PostgreSQL

Dopo l’aggiornamento, il nuovo PostgreSQL non avrà le statistiche delle tabelle a portata di mano. Puoi generarle utilizzando:

cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
VACUUM VERBOSE ANALYZE;
\q
exit
exit

O questa versione in una riga della precedente:

/var/discourse/launcher run app "echo 'vacuum verbose analyze;' | su postgres -c 'psql discourse'"

Pulizia dei vecchi dati

Per un’installazione standard, puoi eliminare i vecchi dati nel formato PG10 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 sorgente 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 qualche minuto finché non è di nuovo attivo.

Ora arrestalo nuovamente con ./launcher stop app. Dopo di ciò, segui i log per verificare se è stato un arresto pulito:

tail -f shared/data/log/var-log/postgres/current
2020-05-13 18:33:33.457 UTC [36] LOG:  received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG:  worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG:  shutting down
2020-05-13 18:33:33.479 UTC [36] LOG:  database system is shut down

Se i log appaiono come sopra, ora puoi provare a eseguire nuovamente l’aggiornamento utilizzando ./launcher rebuild app.

I valori lc_collate per il database “postgres” non corrispondono

Questo errore si verifica se stai utilizzando impostazioni locali non predefinite per il tuo database. È stato segnalato che sono necessarie 3 variabili affinché abbia 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

Sostituendo en_US.UTF-8 con la tua impostazioni locale.

Ogni rebuild esegue nuovamente l’aggiornamento, ovvero ciclo di aggiornamento

Quando ciò accade, i 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

Ciò significa che ci sono ancora file rimasti dall’ultimo aggiornamento. Spostali altrove prima di continuare.

68 Mi Piace
Update failed (postgresql)
Trouble with latest update
Discourse Update Probs. Help please
Cant backup because of version mismatch on aws
User profile page and other features page not available
Error after Upgrading
SAML error after upgrade
Updated to latest version: ./analyze_new_cluster.sh message
Discourse 2.5.0.beta5 Release Notes
Problem with upgrading the latest version
UPGRADE OF POSTGRES FAILED - I've tried everything
Trouble with postgre(maybe)
Postgres upgrade success loop due to prior postgres 8 to 10 migration
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
Failed upgrade from 2.5.0beta4 to 2.5.0beta5
Corrupt indexes in PG12, how do I fix?
PostgreSQL 13 update
Fixing discourse after disk full
LDAP Auth Missing from Plugins
Today error when upgrade from 2.5.1 to 2.5.2, discourse-assign
Discourse for Teams (Alpha Testing summer 2020)
Issue Rebuilding App Failing on Postgres Upgrade
How hard is it to handle Discourse after installation
Primary Postgres database process (postmaster) eating all CPU
Discourse failing to connect to port 3000
Upgrade of postgres failed
Search 502 errors in 2.5.0.beta6
2.6.0 beta 3 update failed on disk and/or memory space
How to backup and restore a whole /var/discourse app folder?
PostgreSQL update wrecked my forum. Please help!
Instead of auto-deleting old replies, make them auto-hide?
Add print CSS for front page and category page?
Site down after failed update: permission denied to create extension "unaccent"
Migrate quickly to separate web and data containers
Rebuild failed - FAILED TO BOOTSTRAP
Old Postgres on Docker Image with two containers: web and data
Can't rebuild due to failed postgres 12 upgrade
Should I also rebuild my data container when upgrading
Old Postgres on Docker Image with two containers: web and data
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
UPGRADE OF POSTGRES FAILED - I've tried everything
PostgreSQL 15 update
Help! Problem with firewall/permissions and postgre?
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
Problem with upgrading the latest version
Restore failed at "EXCEPTION: x of y uploads are not migrated to S3. S3 migration failed for db 'default'."
Trouble with latest update
Can't upgrade due to old docker version
Database migration chokes on huge value of a "calendar-details" item in table "post_custom_fields"
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade