Você tem mais alguns detalhes? Estou vendo o mesmo problema.
1 curtida
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
1 curtida
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.
1 curtida
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.
2 curtidas
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.
1 curtida
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)
Mais cedo no tópico, a equipe afirmou:
Então, sim, é uma opção.
Você já disse:
Erros de colação? Qual é a versão do Discourse atual?
Talvez você possa postar quais erros encontrou / a saída do console.
Mas você não ficou sem espaço (recomenda-se 2 x o tamanho do banco de dados existente)?
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.
1 curtida
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.
Esse é um método perfeitamente válido se você se sentir mais confortável com ele.
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.
2 curtidas
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.
2 curtidas
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.
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.
1 curtida