Boa ideia, obrigado, Ed! Atualizei meu post. 
2 Curtiram
Com essa alteração, estou observando uma redução geral no uso de memória de aproximadamente 4%. Muito bem feito.
2 Curtiram
Obrigado, Lilly, fiz a atualização mais cedo e tudo parece ter dado certo 
1 Curtiu
Não é incomum que tabelas e índices reescritos sejam muito mais compactos.
1 Curtiu
Ah, isso está dentro do ruído operacional do Postgres (dependendo se você olha antes ou depois do vacuum, rebuild da tabela etc.)
Desde então, não percebi que faltasse nada, então, pelo que posso ver, está tudo bem.
1 Curtiu
Estou executando o Discourse em um contêiner Docker standalone em /var/discourse.
Tentei atualizar o banco de dados PostgreSQL embutido da versão 15 para a 18. A atualização parecia ter sido concluída, e o diretório de dados ativo agora relata:
/shared/postgres_data/PG_VERSION
18
No entanto, o contêiner do Discourse reconstruído ainda contém apenas os binários do PostgreSQL 15:
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
O serviço do PostgreSQL está configurado para executar:
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
enquanto o diretório de dados real do Discourse está montado em:
/shared/postgres_data
Consequentemente, o PostgreSQL falha com:
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).
Entendo que as imagens Docker recentes do Discourse devem incluir os binários do PostgreSQL 18. Alterei o app.yml para usar o modelo do PostgreSQL 18 e reconstruí o aplicativo, mas o contêiner resultante ainda tem os binários do PostgreSQL 15 e o script de serviço ainda aponta para /etc/postgresql/15/main.
A parte relevante da minha configuração de serviço atual é:
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
Minhas perguntas são:
-
Qual é a maneira correta de reconstruir ou atualizar o contêiner do Discourse para que ele realmente contenha os binários do PostgreSQL 18?
-
Existe algum modelo ou tag de imagem específico que deve ser usado no
app.yml? -
Uma vez que o PostgreSQL 18 estiver disponível, qual é o procedimento suportado para iniciá-lo contra o diretório existente
/shared/postgres_data?
Não excluí nem reinitializei o diretório de dados do PostgreSQL 18. Prefiro recuperar o cluster atualizado em vez de restaurar os dados antigos do PostgreSQL 15.
1 Curtiu
com base nas instruções do post original, isso parece ter sido uma etapa desnecessária, a menos que eu esteja perdendo alguma coisa?
apenas reconstruir uma instalação padrão deveria ter baixado a imagem mais recente e iniciado a migração.
a menos que você tenha optado por não usar a imagem mais recente, os novos binários certamente estavam garantidos, não é? muito estranho …
tem certeza de que não fixou (pinou) uma imagem?
3 Curtiram
Não intencionalmente? Estou no repositório git e na branch regulares, e não há nada no meu app.yml que indique que eu tenha fixado algo. Eu apenas mudei para o template do postgres 18 para ver se ajudava; sim, isso foi uma etapa desnecessária que não ajudou, então posso reverter.
Alguma sugestão sobre como obter os novos binários? Eles realmente não estão lá, independentemente de quantas vezes eu reconstruo:
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 Curtiu
Para economizar seu tempo e evitar transtornos, eu consideraria usar seu backup mais recente para criar um novo servidor, o que lhe pouparia muito trabalho.
1 Curtiu
Tá, acho que sim! Às vezes não vale a pena se complicar para consertar as coisas. Valeu.
2 Curtiram