Boa ideia, obrigado, Ed! Atualizei meu post. 
2 curtidas
Com essa alteração, estou observando uma redução geral no uso de memória de aproximadamente 4%. Muito bem feito.
2 curtidas
Obrigado, Lilly, fiz a atualização mais cedo e tudo parece ter dado certo 
1 curtida
Não é incomum que tabelas e índices reescritos sejam muito mais compactos.
1 curtida
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 curtida
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 curtida
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 curtidas
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 curtida
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 curtida
Tá, acho que sim! Às vezes não vale a pena se complicar para consertar as coisas. Valeu.
2 curtidas
Quando você não consegue acessar o painel de administração porque seu Discourse decidiu enlouquecer, como você acessa o banco de dados via root@ para enviá-lo a uma nova instância? (talvez outro guia)
Ou qual é o comando de linha de comando para executar a mesma ação que seria feita pelo painel de administração?
Ok, e, mais ao ponto, preciso reconstruir o app para resolver um erro de certificado que parece ter acabado de acontecer (nenhuma alteração antecipada provocou a falha aparente) — o erro de que a porta 443 está acessível está aparecendo (o assistente indica: “Falha na verificação do DNS”) — não sei se o CF ou o DO alteraram algo, mas, de novo, nada foi alterado do meu lado — bem, não consigo reconstruir devido a talvez esses 2 erros, incluindo o abaixo, diferente da última vez, que foi um erro de espaço insuficiente. Alguma ideia de como contornar esse erro abaixo?
Para acrescentar, também recebi exatamente o mesmo erro antes e depois de aumentar o tamanho do disco primário (considerando as necessidades do postgres 15 > 18)
FAILED
--------------------
Pups::ExecError: if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #<Process::Status: pid 17 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
Ah, ok, encontrei o que acho que preciso, postado por @Lilly bem no início deste tópico
cd /var/discourse
./launcher enter web_only
discourse backup
exit
Com base nisso, assumo que consigo gerar um backup do banco de dados utilizável que posso fazer upload em uma nova instância do Discourse e contornar todos os problemas.
Esse comando gera um backup completo, ou seja, posts + uploads/imagens?
Eu recomendo um backup apenas do banco de dados e usar o rsync para transferir todo o resto. Mover um site do Discourse para outro VPS com rsync. Você também pode usar o rsync para transferir os certificados SSL, assim você consegue colocar o novo site no ar antes de alterar o DNS.
É assim que eu faço: Changing Digital Ocean droplets with doctl (resize, floating ip, rename, etc) - Howto - Literate Computing Dashboard
EDIÇÃO: Desculpe. Não consigo dizer se você já resolveu seu problema ou não. Se estou entendendo corretamente, a coisa mais fácil a fazer é voltar para o template padrão, sem versão, e reconstruir novamente.
2 curtidas
Você reconstruiu o container de dados (provavelmente o app, no seu caso) duas vezes, conforme exigido?
(Aliás, a mensagem de atualização diz para reconstruir o app, mas acho que se referia a “o container do banco de dados, que pode se chamar app ou data”, ou significa ambos?)
E um pouco de feedback: há um tempo, tentei fazer a transição da versão 13 para a 15, mas falhou várias vezes e fiquei com o template da versão .13. Agora que a versão .18 foi oferecida, tentei novamente e funcionou sem problemas (só precisei limpar os diretórios _new e _older antes). Então, agora posso usar novamente o template de dados padrão sem versão. Bom trabalho em tornar a atualização tão robusta.
1 curtida
Acabei de notar no log de erros que, antes da atualização do PG, parece haver alguns erros relacionados a SQL nos logs:
Job exception: PG::UndefinedFunction: ERROR: function array_remove(bigint[], integer) does not exist LINE 1: ...ATE "access_control_lists" SET allowed_user_ids = array_remo...
O que é estranho, pois parece que essa função é do PG9, e eu estava usando a versão 15 antes. Isso poderia ser um problema de permissão ou de search path? Parece que o erro não ocorre mais após a atualização do banco de dados, mas talvez seja uma questão de timing do lote… Vejo a função usada em vários lugares, inclusive em scripts de migração.
Talvez isso signifique que algumas funções falham em versões mais antigas do PostgreSQL, mesmo que seus templates ainda estejam listados. Talvez eu tenha perdido isso, mas achei que as versões mais antigas fossem compatíveis.
1 curtida