Apenas um aviso para todos: não tentem essa atualização durante o horário de pico.
A atualização para a versão 2.6.0b2 está rodando no nosso servidor há mais de 40 minutos, quando normalmente leva apenas alguns minutos, geralmente terminando antes mesmo de você voltar a verificar. Fiquei preocupado que tivesse quebrado, mas ao acessar o PostgreSQL, vi uma atualização massiva em execução; parece que está alterando os dados de busca de postagens para mensagens privadas.
Espero que não esteja quebrado. Acho que vou descobrir. Realmente não quero matar o processo ou reiniciar o container no meio da atualização.
Consulta em execução:
postgres=# SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
pid | age | usename | query
-------+-----------------+-----------+---------------------------------------------------------------------------
-------------------
698 | | |
701 | | postgres |
699 | | |
697 | | |
696 | | |
14572 | 00:10:31.484201 | discourse | UPDATE post_search_data
+
| | | SET private_message = X.private_message
+
| | | FROM
+
| | | (
+
| | | SELECT post_id,
+
| | | CASE WHEN t.archetype = 'private_message' THEN TRUE ELSE FALSE END pri
vate_message +
| | | FROM posts p
+
| | | JOIN post_search_data pd ON pd.post_id = p.id
+
| | | JOIN topics t ON t.id = p.topic_id
+
| | | WHERE pd.private_message IS NULL OR
+
| | | pd.private_message <> CASE WHEN t.archetype = 'private_message' THEN T
RUE ELSE FALSE END+
| | | LIMIT 3000000
+
| | | ) X
+
| | | WHERE X.post_id = post_search_data.post_id
+
| | |
14573 | 00:47:02.814489 | discourse | SELECT pg_try_advisory_lock(2859260972035668690)
(7 rows)
A atualização foi bastante lenta para mim, mesmo em hardware de colocalização rápido. Não tenho certeza do motivo, mas é definitivamente algo a se ter em mente.
Sim, sugiro adicionar uma nota no changelog avisando as pessoas de que esta atualização provavelmente levará muito mais tempo do que a maioria, e para não encerrá-la ou tomar nenhuma medida drástica, pois isso é esperado.
Meu site local não tinha tantos posts e ainda assim era bastante lento. Não 40 minutos de atraso, mas notavelmente mais lento do que as atualizações anteriores, talvez 3 a 4 vezes mais?
Obrigado, @Wingtip! Eu achava que isso estava acontecendo apenas conosco!
Na verdade, precisei cancelar a reconstrução e reiniciar o aplicativo porque pensei que ele tivesse travado naquela consulta que você mencionou. Temos 6 milhões de postagens e, após cerca de 45 minutos, ainda não havia concluído. Então, acho que terei que me preparar para pelo menos uma hora de reconstrução e avisar nossos usuários antes disso.
Acabei de usar um cronômetro e testei uma reconstrução (site com cerca de 1 milhão de posts) da versão 2.6.0b1 para a b2; do início ao fim, levou 170 segundos.
Eu também não uso o gerenciador do Docker e prefiro reconstruir pela linha de comando. É melhor assim para ver o log caso algo dê errado. Também acho que é mais rápido.
Eu tinha um site grande que falhava repetidamente ao iniciar. É uma instalação de 2 contêineres, então o contêiner antigo continuava rodando enquanto a inicialização realizava a migração. Acabei resolvendo o problema ativando SKIP_POST_DEPLOYMENT_MIGRATIONS=1 para a inicialização e, em seguida, executando as migrações após o novo contêiner ser iniciado. Com SKIP_POST_DEPLOYMENT_MIGRATIONS=1 na seção ENV, a migração foi muito rápida, e o site pôde funcionar normalmente (embora talvez um pouco mais lentamente) enquanto as migrações ocorriam, o que levou, acho eu, mais de 20 minutos.
Acredito, embora ainda não tenha testado, que usar o mesmo truque funcionaria para minimizar o tempo de inatividade durante uma instalação de único contêiner. Se eu estiver certo, o que você faria seria:
adicionar SKIP_POST_DEPLOYMENT_MIGRATIONS=1 ao seu app.yml
./launcher rebuild app
./launcher enter app
SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate
desfazer a edição no app.yml, a menos que planeje lembrar de executar as migrações após cada atualização
talvez reconstruir novamente para garantir que você não tenha nenhum problema enquanto ainda se lembra do que poderia ter quebrado seu site, pois, daqui a 4 meses, quando tentar novamente, não fará ideia e será difícil para qualquer um adivinhar qual poderia ser o problema
Se houvesse uma maneira de o ./launcher passar SKIP_POST_DEPLOYMENT_MIGRATIONS=1 para as coisas sem exigir uma edição no app.yml, tornaria as coisas menos complicadas para quem tem dificuldade com edição.
Se eu conseguir realizar o trabalho sobre isso que acredito que farei, criarei um novo tópico relatando o que descobri. Embora a fumaça me tenha confinado a um quarto onde não tenho meu monitor grande. (A pandemia não foi suficiente?! Temos que ter fumaça também? E eu nem estou especialmente perto do maldito incêndio.)
Isso é uma notícia fantástica! (Outros dois projetos atrapalharam hoje e, de alguma forma, minha instância multisite parou de funcionar e de se dar bem com o S3. ) Muito obrigado.
Existe algum motivo técnico para que as alterações no banco de dados após a atualização sejam bloqueantes por padrão? Há alguma maneira de alterar esse comportamento para que as futuras atualizações restaurem o site rapidamente e, em seguida, executem as tarefas pós-atualização em segundo plano?
Na minha opinião, qualquer coisa essencial para o funcionamento da aplicação atualizada, como DDL, deveria fazer parte da própria atualização, e não de scripts pós-atualização.
Edição: enquanto isso, matei o processo para colocar o site no ar novamente para nossos usuários. Mas tem que haver uma maneira melhor de fazer essa atualização.
) Muito obrigado.