Problema na reconstrução devido ao desligamento lento do banco de dados

Obrigado — então ./launcher rebuild web_only (ou rebuild data) em vez de ./launcher rebuild app, e eu precisaria ler atentamente as atualizações para ver quando o postgres ou o redis são atualizados para atualizá-los manualmente também. E a principal vantagem sobre o standalone é que os rebuilds não precisam esperar o banco de dados desligar e depois iniciar novamente, revertendo transações se ele foi encerrado.

Mas com as últimas alterações do Falco, o banco de dados nunca deve ser encerrado, a menos que leve mais de 10 minutos para desligar, o que certamente não acontecerá, a menos que tenhamos muito mais usuários. Portanto, as atualizações não falharão devido a esse problema, e o principal impacto é apenas tornar as atualizações alguns minutos mais longas.

Minha leitura é que, no final, a mudança adiciona um monte de complexidade e sobrecarga mental por um ganho muito pequeno. Por favor, corrija-me se eu estiver errado, isso não é para ser sarcástico/etc.

Apenas como um pouco de contexto, a mudança teria que oferecer benefícios substanciais para valer a pena essa sobrecarga, porque tudo isso é um favor não remunerado meu (um que agora se estende por mais de 15 anos, mas ainda assim), não é meu trabalho. Situação de YMMV (Your Mileage May Vary - Sua Milhagem Pode Variar) real aí.

Certo.

Muitas pessoas compartilham essa opinião, o que continuo achando surpreendente. As atualizações do Postgres vêm menos de uma vez por ano, e geralmente não há penalidade por atrasá-las por meses após a mudança inicial. Ter uma configuração de 2 contêineres significa que você pode atrasar a atualização do postgres mais facilmente do que se tiver um único contêiner, o que me parece outra vantagem.

Com a configuração de 2 contêineres, você pode

 ./launcher bootstrap web_only && ./launcher destroy web_only; ./launcher start web_only

e ter (tipicamente) menos de um minuto de inatividade.

Mas você não quer, então não o faça.

3 curtidas

Atrasar as atualizações do postgres historicamente significou uma simples alteração no yaml de configuração, a menos que vocês planejem parar de dar suporte a isso. Podemos lidar com alguns minutos extras de inatividade para atualizações e, aos meus olhos, isso representa menos risco do que depender de uma pessoa (que sou eu!) para manter adequadamente uma configuração menos padrão e mais complexa.

Do meu ponto de vista, a principal vantagem de dois contêineres é a redução do tempo de inatividade - como você, eu acho, estou bem com 20-30 minutos de inatividade a cada poucos meses. Mas é fácil ver que para alguns fóruns isso é demais.

1 curtida

Com certeza. Mesmo que estivéssemos falando de 90 minutos de inatividade contínua versus 5 minutos separados, eu ainda provavelmente não acharia que a mudança valeria a pena, embora eu provavelmente fizesse atualizações no final da noite em vez de convenientemente no meio do dia se levasse tanto tempo. Não somos uma plataforma de negociação de ações em tempo real, somos um fórum gratuito sobre videogames.

Com a configuração de 2 contêineres, isso significa que você nem precisa saber fazer essa alteração simples. E haveria zero chance de você iniciar uma atualização e depois descobrir que já havia iniciado a atualização do postgres.

Mas passei quase 35 anos vivendo em um shell.

E agora tenho um painel que automatiza essas atualizações de linha de comando (e lida com atualizações do postgres e um monte de outras coisas).

Mas não conserte o que não está quebrado, e eu entendo que mover coisas e potencialmente quebrá-las é assustador.

2 curtidas

Eu comecei no Slackware, eu só não vejo a manutenção do fórum como um projeto divertido e quero que ele desapareça para que eu possa continuar batendo minha cabeça contra a parede tentando fazer o Google Home se integrar com o Home Assistant (ou qualquer outra coisa que me agrade naquela semana).

1 curtida