Atualização do PostgreSQL 12

:warning: AVISO! Se o seu banco de dados for muito grande, você precisará de muito espaço extra em disco (2x o tamanho do banco de dados) e deve ter muito cuidado com esta atualização!

Acabamos de implementar a tão aguardada atualização de versão principal do PostgreSQL. Qualquer administrador de site que reconstrua o Discourse a partir da linha de comando será atualizado do PostgreSQL 10 antigo para o PostgreSQL 12.

Estamos executando esta nova versão há algum tempo no Meta e tudo está funcionando bem. O PostgreSQL 12 traz muitas melhorias que serão aproveitadas automaticamente pelo Discourse.

Atualizando

Guia de Instalação Oficial (contêiner único)

Na sua próxima reconstrução, você verá esta mensagem no final:

Atualização Concluída
----------------

Para concluir a atualização, reconstrua novamente usando:

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

Isso significa que tudo correu bem na atualização! Você só precisa emitir uma nova reconstrução para colocar seu site de volta no ar.

Instalação com Contêiner de Dados

Se você estiver executando uma configuração com um contêiner de dados dedicado baseado no exemplo fornecido em nosso repositório discourse_docker, certifique-se de desligar o PostgreSQL de forma segura e limpa.

Atualmente, temos trabalhos em segundo plano executando consultas que levam vários minutos, então desligar o contêiner web ajudará o contêiner de dados a ser desligado com segurança.

./launcher stop web_only
./launcher stop data
./launcher rebuild data
./launcher rebuild data
./launcher rebuild web_only

Antes de emitir a primeira reconstrução para o contêiner de dados, você pode acompanhar o log do PostgreSQL para ver se ele foi desligado corretamente.

Executar tail -f shared/data/log/var-log/postgres/current deve fornecer o seguinte log se foi limpo:

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

Realizando uma atualização manual / ambientes com espaço limitado

:warning::warning::warning:
VOCÊ DEVE FAZER BACKUP DOS DADOS DO POSTGRES ANTES DE TENTAR ISSO
:warning::warning::warning:

Se você estiver em um ambiente com espaço limitado e sem nenhuma maneira de obter mais espaço, pode tentar o seguinte:

./launcher stop app #(ou ambos web_only e data se for o seu 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 #(ou primeiro data e depois web_only se for o seu caso)

Nos meus testes, este procedimento requer menos de 1x o tamanho atual do seu banco de dados em espaço livre.

Adiar a atualização

Se precisar adiar a atualização na sua próxima reconstrução, você pode trocar o template do PostgreSQL no seu arquivo app.yml alterando "templates/postgres.template.yml" para "templates/postgres.10.template.yml".

Isso não é recomendado, pois alguns administradores de site podem esquecer de reverter a alteração depois.

Tarefas opcionais pós-atualização

Otimizando estatísticas do PostgreSQL

Após a atualização, o novo PostgreSQL não terá estatísticas de tabela em mãos. Você pode gerar essas estatísticas usando:

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

Ou esta versão de uma linha do acima:

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

Limpando dados antigos

Para uma instalação padrão, você pode excluir os dados antigos no formato PG10 com o seguinte comando:

cd /var/discourse
./launcher cleanup

Se você tiver um contêiner de dados separado, precisará remover a cópia de backup assim:

rm -fr /var/discourse/shared/data/postgres_data_old/

FAQ

O cluster de origem não foi desligado corretamente

Se você receber uma falha na atualização com a mensagem acima, pode tentar uma abordagem mais simples para colocá-lo de volta em um estado melhor.

Reinicie o contêiner antigo com ./launcher start app. Aguarde alguns minutos até que ele volte ao ar.

Agora desligue-o novamente com ./launcher stop app. Depois disso, acompanhe os logs para ver se foi uma desligamento limpo:

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 os logs parecerem como acima, você pode agora tentar atualizar novamente usando ./launcher rebuild app.

Os valores de lc_collate para o banco de dados “postgres” não correspondem

Esse erro ocorre se você estiver usando localizações não padrão para seu banco de dados. Foi relatado que você precisa de 3 variáveis para que isso tenha sucesso. Certifique-se de que a seção env: do seu arquivo app.yml tenha as 3 linhas:

  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8

Alterando en_US.UTF-8 para sua localização.

Toda reconstrução faz a atualização novamente, ou seja, loop de atualização

Quando isso acontece, seus logs de atualização conterão:

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

Isso significa que ainda há arquivos da última atualização espalhados. Mova-os para outro lugar antes de continuar.

68 curtidas
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