Deixe o Discourse cuidar disso. Isso requer 3 vezes o espaço em disco. Então, se seu banco de dados tem 100 GB, você precisaria de 200 GB livres adicionais para fazer a atualização. Obviamente, um grande problema para quem tem instalações grandes.
Siga o procedimento de “atualização manual” deles. Isso requer 2 vezes o espaço em disco, então, se seu banco de dados tem 100 GB, você precisaria de 100 GB livres adicionais. Isso também é um grande problema para alguns.
Em esta postagem, @Falco sugeriu usar a opção --link para fazer a atualização no local usando links rígidos. O contêiner Docker que eles sugerem usar suporta esse argumento, mas os desenvolvedores do Discourse não recomendam seu uso na postagem.
Então, minha pergunta é: a opção 3 deve ser:
Execute o comando abaixo, que exigirá uma quantidade muito pequena de espaço em disco adicional. Então, se seu banco de dados tem 100 GB, pode exigir, digamos, 10 GB adicionais? E, em caso afirmativo, isso é um procedimento recomendado pelos desenvolvedores do Discourse, e alguém já fez isso antes e sobreviveu para contar a história?
Comando novo para atualizar no local:
docker run --rm \
-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
tianon/postgres-upgrade:12-to-13 \
--link
Compared to the old command to upgrade into a new directory (requiring double the space):
P.S.: Eu teria apenas respondido àquele tópico de atualização do PG13, mas ele exclui postagens após 7 dias. Por que vocês configuraram dessa forma? Sei que houve muita discussão quando isso surgiu pela primeira vez, o que teria sido útil como referência.
Se fizeram, não mencionaram aqui. A maioria das instruções aqui tenta ser o mais à prova de erros possível e exige o mínimo de conhecimento em administração de sistemas. A maioria das pessoas aqui prefere fazer algo da maneira mais segura e mais testada possível, em vez de seguir um método projetado para economizar algumas poucas dólares.
Se funcionar para você, você pode atualizar a atualização do PostgreSQL 13 de acordo, mas antes de fazê-lo, você se sente confortável em recomendar que alguém que não sabe o que é bash faça isso dessa maneira? Tem certeza de que não vai corromper o banco de dados deles e que o site deles ficará arruinado para sempre?
A ideia é que, se alguma outra informação útil for apresentada, ela seja adicionada à OP, em vez de pedir às pessoas que leiam um ano inteiro de postagens que provavelmente serão inúteis ou incorretas.
Não, não tenho certeza. Não tenho muita experiência com PostgreSQL e esperava que um dos desenvolvedores do Discourse pudesse dar algumas garantias de que funcionaria.
Mesmo que funcione, também não o recomendaria como o procedimento de atualização padrão, pois o método antigo mantém uma cópia separada do banco de dados para reversão. Se funcionar, seria uma ótima opção para ambientes com restrições de espaço, no entanto.
Outra maneira fácil é iniciar um novo servidor, migrar os dados e desligar o antigo. Se você for obrigado a usar o antigo, faça a atualização em um servidor temporário, assim você terá uma instalação limpa no servidor original (que provavelmente precisa de uma atualização do sistema operacional) e depois o moverá de volta.
Isso é seguro, fácil e bem documentado. Centenas de pessoas já fizeram isso.
Sim, mas isso levaria um ou dois dias. Durante esse período, poderíamos ou a) informar aos usuários que suas postagens nesse período serão perdidas ou b) deixar o fórum apenas para leitura. Nenhuma das duas opções é uma solução ideal.
Não acho que o servidor ficaria fora do ar muito mais tempo do que durante a reconstrução. E se você migrar para o novo servidor e permanecer lá, pode deixar o servidor antigo no modo somente leitura enquanto faz a migração. Se a preocupação é o tempo de inatividade, migrar para um novo servidor será muito, muito melhor.
Temos um fórum bastante grande, mas nunca tentei restaurar um backup, então não sei quanto tempo levaria. Se fizermos isso, realmente permaneceríamos no novo hospedador. Gostaria de evitar isso, se possível, devido ao trabalho extra e às inconveniências.
Outra forma de resolver o problema de upgrade com espaço limitado é fazer um backup, remover o diretório do postgres com rm -r, reconstruir e, em seguida, restaurar o backup. Fiz isso em um site na semana passada.
Não, nunca consegui atualizá-lo. Excluir o banco de dados e restaurar o backup parece bastante arriscado. Precisamos que a atualização no local funcione, basicamente.
Estamos executando o Ubuntu 18.04, que será descontinuado em 2023, então imagino que nesse ponto não teremos escolha a não ser migrar para um novo host de qualquer maneira, e planejamos engolir o sapo então, montar um novo host executando o 22.04 LTS e restaurar a partir do backup.
Hmm. Pode ser um empate. Acho que com o modelo de backup uma das cópias está compactada, o que pode fazer a diferença? E o site em que fiz isso tinha backups no S3. E era um site de teste, então as apostas eram baixas se houvesse um problema.
Exceto que os backups são usados com muito mais frequência em muito mais situações do que o upgrade in-place. Eu considero muito mais seguro.
Talvez, mas não tenho muita experiência com postgres e não me sinto confortável em fazer isso. Restaurar o site inteiro do backup em uma VM completamente diferente, isso eu me sinto confortável em fazer, no entanto, significaria perder posts por quantas horas forem necessárias para restaurar, então também não estou super entusiasmado com isso. Mas como o 18.04 está sendo descontinuado, não terei muita escolha no ano que vem.
A menos que seu banco de dados tenha dezenas de gigabytes, não levará horas. E você colocará o fórum em modo somente leitura antes de fazer backup e restaurar, então não perderá nenhum post. Não é tão difícil de fazer com virtualmente nenhum tempo de inatividade, apenas tempo somente leitura.
root@forum-app:/shared/postgres_data# du -sh
97G .
Eu não colocaria em modo somente leitura, eu colocaria um banner dizendo às pessoas que suas postagens de hoje são efêmeras. Melhor deixá-los conversar sobre isso, mesmo que essas postagens sejam perdidas, na minha opinião.
Até lá, você também terá acesso ao chat integrado do Discourse, um recurso que será lançado na versão 2.9 (possivelmente desativado por padrão, mas em beta e com suporte para uso).