Atualização do PostgreSQL 18 para self-hosters

[Moin]

@NateDhaliwal

Corrigido com a ajuda do ChatGPT. Não sou nenhum mestre em Linux/Postgres.

Você tem mais alguns detalhes? Estou vendo o mesmo problema.

[Moin]

Para aqueles que também estão vendo o mesmo, este é o resumo (IA) do que eu fiz:
Iniciar temporariamente o PG15 → Fazer dump do banco de dados → Usar o PG18 → Restaurar o dump

[merefield (Robert)]

Então, sim, esta atualização é baseada em imagem.

Então, mesmo que você escolha instalar uma versão antiga do Discourse, a imagem ainda forçará uma atualização para a versão 18?

Entendi.

[NateDhaliwal]

Vejo que você corrigiu o problema, mas o método que o ChatGPT forneceu, embora tenha corrigido o erro, acabou apagando meu banco de dados, então, essencialmente, não há mais contas, tópicos ou mensagens.

Felizmente, era um fórum de desenvolvimento relativamente novo, então não perdi tanto assim.

[Moin]

Foi exercido grande cuidado para garantir que isso não acontecesse hoje. Após cada etapa, o sistema me informava que nada seria excluído, e tive a impressão de que verificamos três vezes se todos os dados haviam sido migrados antes de concordarmos em excluir o que já não precisávamos.

Mas, se algo tivesse dado errado, os únicos dados que eu teria perdido seriam a configuração do componente do tema.

[Saiano]

Olá, tenho um fórum com um banco de dados bastante grande (cerca de 80 GB). Para a migração da versão 13 para a 15, mudei de servidor, fiz uma nova instalação e restaurei os dados.
Vocês recomendam fazer a mesma migração? (tentei fazer a atualização, mas tive erros de colação)

[Andrew_Rowe]

@Saiano

Para a atualização da versão 13 para a 15, mudei de servidor, fiz uma instalação limpa e restaurei os dados.
Vocês ainda recomendam essa abordagem?

Mais cedo no tópico, a equipe afirmou:

@chrisr

@pfaffman

é muito mais seguro do que atualizar uma versão principal do banco de dados.

É verdade, mas estamos buscando um mecanismo de atualização simples e transparente. Ambas as abordagens têm seus méritos.

Eu diria: faça o que você se sentir mais confortável e não tenha medo de personalizar os modelos no discourse_docker conforme suas necessidades. Obviamente, o principal é testar primeiro e ter um plano de rollback.

Então, sim, é uma opção.

Você já disse:

@Saiano

Tentei a atualização direta, mas encontrei erros de colação

Erros de colação? Qual é a versão do Discourse atual?

Talvez você possa postar quais erros encontrou / a saída do console.

@Saiano

um banco de dados bastante grande (cerca de 80 GB)

Mas você não ficou sem espaço (recomenda-se 2 x o tamanho do banco de dados existente)?

[Saiano]

Oi, tenho espaço (250 GB livres). O erro era “colation mismatch”, mas acho que não tenho as strings utf no arquivo app.yml.

[chrisr (Chris Rendle-Short)]

@merefield

Então, mesmo que você escolha instalar uma versão antiga do Discourse, a imagem ainda vai forçar uma atualização para a versão 18?

Tentamos fornecer configurações padrão sensatas nas imagens do discourse_docker, mas não é possível prever todos os casos de uso possíveis. Sinta-se à vontade para personalizar suas imagens para manter versões anteriores, se preferir.

Em certa medida, as versões das dependências refletem nossos requisitos de hospedagem — usamos a imagem base internamente. Isso significa que ela não deve ficar muito desatualizada, mas também significa que só podemos manter um número limitado de permutações.

@Saiano

Olá, tenho um fórum com um banco de dados bastante grande (cerca de 80 GB). Para a atualização da versão 13 para a 15, mudei de servidor, fiz uma instalação limpa e restaurei os dados.
Vocês ainda recomendam essa abordagem? (Tentei a atualização direta, mas encontrei erros de colação)

Esse é um método perfeitamente válido se você se sentir mais confortável com ele.

@Saiano

o erro foi “colação incompatível”

Se o aviso for gerado durante a preparação para fazer o dump do banco de dados antigo, não há motivo para preocupação. Estamos executando o servidor apenas contra o diretório de dados antigo para o propósito de rodar o pg_dump. Quando o dump é restaurado no novo servidor, os índices são recriados.

O motivo pelo qual você está vendo isso é que, nos últimos dias, lançamos uma nova versão da imagem base que atualiza do Debian Bookworm para o Trixie, alterando a versão da glibc. Locais baseados no provedor libc (que você provavelmente estava usando) não são estáveis entre atualizações da glibc, então quando o script de atualização inicia um servidor Postgres para fazer o dump dos seus dados antigos, ele exibe avisos de incompatibilidade de colação.

A incompatibilidade de colação é exatamente o motivo pelo qual estamos fazendo o dump e restauração em vez de rodar o pg_upgrade. Uma vez que seu banco de dados estiver usando C.UTF-8 com o provedor builtin, atualizações da glibc não afetarão mais as colações.

[Jonathan5]

@chrisr

Se o aviso for gerado durante a preparação para despejar o banco de dados antigo, não há motivo para preocupação.

Realizei a atualização esta noite e tudo ocorreu conforme o planejado. Recebi os mesmos avisos sobre colação do banco de dados, mas parece que devemos ignorá-los. Obrigado.

[Saiano]

Tentei inserir no app.yml

app.yml
templates:

• “templates/postgres.15.template.yml”
• “templates/redis.template.yml”
• “templates/web.template.yml”
• “templates/web.ratelimited.template.yml”

Para adiar a atualização, mas estou com este erro

Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Local do erro: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.

[pfaffman (Jay Pfaffman)]

Parece que o container base está errado, acho. Você executou um ./launcher rebuild? Isso deveria fazer um git pull, mas você pode tentar rodar um git pull para ver se isso muda alguma coisa.

[Saiano]

Mesmo erro

Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Status: Imagem mais recente baixada para discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
Garantindo que o launcher está atualizado
Launcher está atualizado
Parando o antigo contêiner

• /usr/bin/docker stop -t 600 app
  app
  2.0.20260812-0036: Obtendo da discourse/base
  Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
  Status: Imagem está atualizada para discourse/base:2.0.20260812-0036
  docker.io/discourse/base:2.0.20260812-0036
  /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups.rb
  /usr/local/bin/pups --stdin
  I, [2026-08-25T06:22:16.249062 #1] INFO – : Lendo da entrada padrão (stdin)
  I, [2026-08-25T06:22:16.274434 #1] INFO – : Arquivo > /etc/service/postgres/run chmod: +x chown:
  I, [2026-08-25T06:22:16.281650 #1] INFO – : Arquivo > /etc/service/postgres/log/run chmod: +x chown:
  I, [2026-08-25T06:22:16.287846 #1] INFO – : Arquivo > /etc/runit/3.d/99-postgres chmod: +x chown:
  I, [2026-08-25T06:22:16.293208 #1] INFO – : Arquivo > /root/install_postgres chmod: +x chown:
  I, [2026-08-25T06:22:16.299851 #1] INFO – : Arquivo > /root/upgrade_postgres chmod: +x chown:

FALHOU

Errno::ENOENT: Arquivo ou diretório não encontrado @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Local da falha: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
A substituição falhou com os parâmetros {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
O bootstrap falhou com o código de saída 1
** FALHA NO BOOTSTRAP ** role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.
2d15a756bfd82ed45debfbb4936784721293a3aeecabe8ba9b58c64d4bbe16e1

[Ethsim2 (Ethan)]

@Saiano

Mesmo erro

Acredito que encontrei a causa.

A imagem base atual instala o servidor PostgreSQL 18, mas o postgres.15.template.yml ainda assume que os pacotes do servidor PostgreSQL 15 já estão presentes. Como resultado, ele tenta acessar:

/etc/postgresql/15/main/postgresql.conf

anteriormente à existência desse arquivo, gerando o erro ENOENT mencionado acima.

Abri um pequeno PR que faz com que o template de retenção do PostgreSQL 15 remova os pacotes do servidor PostgreSQL 18 e instale os pacotes do servidor PostgreSQL 15 antes de configurar o PostgreSQL:

FIX: install PostgreSQL 15 server in postgres.15 template (#1120)

Isso deve restaurar o caminho pretendido, no qual a alteração de postgres.template.yml para postgres.15.template.yml adia a atualização para o PostgreSQL 18.

[Saiano]

A atualização foi lançada?
Quando poderei tentar novamente? (apenas para informação)

[chrisr (Chris Rendle-Short)]

Mergi a correção (obrigado, @Ethsim2!), então você já pode tentar novamente.

[Saiano]

@chrisr

Apliquei a correção (obrigado @Ethsim2!), então você deve conseguir tentar novamente.

Funciona, obrigado!

[AstonJ]

A atualização funcionou bem para quem tem vários contêineres no mesmo servidor? Se eu tiver tempo neste fim de semana, talvez eu faça a atualização do nosso — só queria conferir aqui primeiro, caso eu deva esperar um pouco mais…

[Lilly (Lillian)]

sim, eu fiz atualizações em contêineres duplos em um servidor há algumas semanas (também em um servidor russo). Não tive nenhum problema, mas certifique-se de ter espaço em disco suficiente antes.

[Eviepayne (vladtheimplier)]

Dica para quem faz atualizações do Postgres fora do Docker. Você pode usar --link no pg_upgrade para não precisar copiar os dados. É possível criar hard links dos dados. Isso economiza espaço em disco.