O painel do Literate Computing atualizou com sucesso dois sites independentes e um site de dois contêineres sem incidentes. Na maioria dos casos, tudo o que era necessário era alterar a versão alvo do Postgres em uma variável, então, conforme anunciado, o processo é o mesmo dos últimos.
Na verdade, é bastante suportado, é muito mais seguro do que atualizar uma versão principal do banco de dados. Se algo der errado, você simplesmente não faz a troca para o novo servidor. Se você estiver perto de precisar de uma atualização do SO e/ou quiser tempo de inatividade mínimo, é uma boa opção. Você tem acesso somente leitura enquanto constrói o novo servidor e depois faz a troca. A maneira fácil tem apenas tempo de inatividade para a reconstrução final, ou zero tempo de inatividade se você copiar os certificados do servidor antigo).
Se tudo der errado com uma atualização do banco de dados, construir um novo servidor e restaurar o backup é a solução fácil.
Certifique-se de fazer um backup antes de começar. Eu faço um backup apenas do banco de dados, já que você não vai perder seus uploads.
Só para confirmar, não estou usando o PostgreSQL fornecido pelo Discourse e o próprio Discourse ainda não exige o PG18, correto? Então, não sou obrigado (ainda) a fazer a atualização para o PG18.
Bom ponto. Mas o outro aspecto é que as versões LTS saem a cada dois anos, então não é uma má ideia fazer isso ao mesmo tempo.
Você tem bastante tempo. Eles pressionaram por… hum, alguma versão bem rápido após a atualização devido a algum recurso que era necessário, mas você provavelmente pode esperar até um ano. Eu acompanho o repositório discourse_docker. Em algum ponto eles começarão a falar sobre remover o suporte ao PG15; não é especialmente barulhento e é uma maneira fácil de se manter atualizado com as mudanças internas.
Isso pode incentivar outros a seguir nossos passos intrepides mais cedo.
Minha IA de busca web gratuita está me dizendo:
Para um aplicativo Rails típico, migrar do PostgreSQL 15 → 18 pode resultar em ~10–25% de melhoria no desempenho das consultas sem alterações no código, e até 40% em padrões de consulta específicos, se você aproveitar os novos recursos de indexação e do planejador.
Se for verdade, essa é uma atualização bem interessante!
É verdade, mas nosso objetivo é um mecanismo de upgrade simples e transparente. Existem vantagens em ambas as abordagens.
Diria que faça o que te deixar mais confortável e não tenha medo de personalizar os templates no discourse_docker conforme suas necessidades. Obviamente, o mais importante é testar primeiro e ter um plano de rollback.
Em nossa plataforma hospedada, pretendemos fazer mais testes e benchmarks antes de ativá-las, e por isso as desativei no discourse_docker também para alinhar a configuração. No entanto, não é estritamente necessário desativá-las (usamos internamente apenas a parte do container web do discourse_docker) e eu não me oporia a ativá-las.
Um possível problema é que o pg_upgrade não funcionará se os diretórios de dados antigo e novo tiverem configurações de checksum diferentes. O processo seria: desligar o servidor PG15, executar o pg_upgrade para convertê-lo para PG18 sem checksums, executar o pg_checksums para habilitar as checksums e, em seguida, iniciar o PG18. Isso não é um problema ao fazer dump e restore (como nesta atualização), mas é algo a se observar.
Note que as checksums de dados estão disponíveis desde o Postgres 9.3, mas até agora estavam desativadas por padrão. O Postgres 19 também incluirá a capacidade de habilitá-las/desabilitá-las online.
Não, não neste momento. A maioria das funcionalidades do Discourse usa o adaptador PostgreSQL do Rails para se comunicar com o banco de dados, mas o backup/restore usa pg_dump e psql no container web. Atualmente, estamos instalando os clientes PG15 e PG18 para permitir backup/restore usando ambas as versões, mas em algum momento no futuro removeremos o PG15.
O fator determinante foi a mudança para o novo provedor de locale integrado. Estamos trabalhando em um upgrade do SO em nossa plataforma hospedada e queremos quebrar o acoplamento com a glibc.
e7f1201 adicionou o cliente PG18 à imagem web para compatibilidade de backup. Se você não estiver usando nenhum dos componentes do servidor Postgres do discourse_docker, esta é a revisão mais antiga que você deve usar para PG18.
Eu estava falando sobre uma ou duas atualizações atrás.
Concordo. Meu ponto era apenas que não há menos suporte para poder restaurar um backup antigo do Postgres em uma versão mais nova. O mecanismo de atualização in-place funciona incrivelmente bem para a grande maioria das pessoas, mas quando algo dá errado, é difícil saber o que fazer (principalmente porque isso acontece com tanta rareza).
