AVISO! A atualização exige bastante espaço livre em disco (2x o tamanho do banco de dados).
Acabamos de implementar alterações para atualizar nossa imagem Docker para o PostgreSQL 18. Qualquer administrador de site que reconstruir o Discourse pela linha de comando será atualizado do PostgreSQL 15 anterior para o PostgreSQL 18. Observe que, se você evitou a atualização quando a atualização do PostgreSQL 15 aconteceu em 2025, você pode pular essa atualização e ir diretamente para o PostgreSQL 18.
Se você evitou a atualização anteriormente, altere o modelo do PostgreSQL em app.yml de templates/postgres.13.template.yml para templates/postgres.template.yml.
Como em qualquer atualização, é fortemente recomendado fazer um backup antes de fazer qualquer coisa.
Alterações de localidade
Anteriormente, já vimos corrupção de índice ocorrer quando o glibc era atualizado, como durante atualizações do SO. Desde o PostgreSQL 17, há um novo provedor de localidade integrado que é desacoplado do glibc do SO e, portanto, estável entre versões. Como parte desta atualização, estamos migrando para este provedor integrado usando a localidade C.UTF-8. Esta localidade usa ordenação por ponto de código e a recomendamos pelos motivos de estabilidade mencionados acima.
Para realizar a alteração de localidade, precisamos primeiro criar o novo cluster de banco de dados usando o provedor de localidade integrado e, em seguida, fazer o dump e restaurar o banco de dados neste cluster. Por este motivo, os requisitos de espaço em disco são maiores do que nas atualizações anteriores, onde realizávamos atualizações no local.
Atualização
Guia de Instalação Oficial (contêiner único)
Na sua próxima reconstrução, você verá esta mensagem no final:
-------------------------------------------------------------------------------------
ATUALIZAÇÃO DO POSTGRES CONCLUÍDA
O banco de dados 15 antigo está armazenado em /shared/postgres_data_old
Para concluir a atualização, reconstrua novamente usando:
./launcher rebuild app
-------------------------------------------------------------------------------------
Isso significa que tudo ocorreu 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 modelo fornecido em nosso repositório discourse_docker, certifique-se de estar desligando o PostgreSQL de forma segura e limpa.
Hoje em dia, temos jobs em segundo plano executando consultas que levam vários minutos, então desligar o contêiner web ajudará a desligar o contêiner de dados 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 monitorar o log do PostgreSQL para ver se ele foi desligado corretamente.
Executar um tail -f shared/standalone/log/var-log/postgres/current deve fornecer o seguinte log se foi limpo:
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
Adiando a atualização
Se você precisar adiar a atualização durante sua próxima reconstrução, pode alternar o modelo do PostgreSQL em seu arquivo app.yml, alterando "templates/postgres.template.yml" para "templates/postgres.15.template.yml".
Isso não é recomendado, pois alguns administradores de site esquecerão de reverter a alteração posteriormente.
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 tabelas disponíveis. Você pode gerar essas estatísticas usando:
docker exec -u postgres app \
/usr/lib/postgresql/18/bin/vacuumdb -d discourse --analyze-in-stages
Limpando dados antigos
Para uma instalação padrão, você pode excluir os dados antigos no formato PG15 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 em um estado melhor.
Reinicie o contêiner antigo com ./launcher start app. Aguarde alguns minutos até que ele esteja de volta.
Agora desligue-o novamente com ./launcher stop app. Após isso, monitore os logs para ver se foi um desligamento limpo:
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 os logs não indicarem que o banco de dados foi desligado, você pode iniciar o contêiner antigo novamente, entrar com ./launcher enter app, executar esses comandos e monitorar os logs novamente ao terminar.
export SVWAIT=300
sv stop nginx
sv stop unicorn
sv stop postgres
exit
Se os logs parecerem com os acima, você pode tentar atualizar novamente usando ./launcher rebuild app.
Valores de lc_collate para o banco de dados “postgres” não correspondem
Este erro ocorre se você estiver usando localidades não padrão para seu banco de dados. Foi relatado que você precisa de 3 variáveis para que 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 localidade.
Cada 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 por perto. Mova-os para outro lugar antes de continuar.
Eu pulei a atualização do PostgreSQL 15, o que fazer agora?
Você pode seguir as instruções padrão no topo deste guia e elas atualizarão de sua versão para a 18 sem problemas.
