Esta atualização recomendada falhou e não restaurou meu fórum após quebrá-lo. Estou executando o discourse-doctor agora para tentar consertá-lo e, se isso também falhar, fiz um snapshot da VM.
Saída:
2023-04-19 18:28:31.298 UTC [42] LOG: received fast shutdown request
2023-04-19 18:28:33.651 UTC [65] LOG: shutting down
2023-04-19 18:28:33.974 UTC [42] LOG: database system is shut down
FAILED
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 59 exit 2>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"'"
bootstrap failed with exit code 2
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
Command exited with non-zero status 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps
Editar: O Discourse-doctor nos colocou de volta em funcionamento.
Eu basicamente pedi por isso, atualizando uma hora depois dessa notificação e sendo o primeiro a fazê-lo. Sem estresse real com esse snapshot antes, então eu fiz isso pela equipe, pessoal.
2023-04-19 18:28:26.755 UTC [45] LOG: o sistema de banco de dados não foi encerrado corretamente; recuperação automática em andamento
Se o seu banco de dados não conseguir parar com segurança em 60s, o que acontecerá com bancos de dados grandes e discos mais lentos, ele entrará neste estado e falhará na reconstrução se não conseguir se recuperar em 5s (o que é raro, já que é grande/lento).
Isso não tem nada a ver com as alterações listadas aqui, e é um problema no Discourse desde pelo menos 2016.
Ahh, obrigado. Talvez devesse esperar mais tempo para fóruns maiores como o nosso. Se você simplesmente encerrar o processo do banco de dados, ele precisará reverter as transações após ser reiniciado, e isso pode levar muito tempo.
A terminologia sobre beta é um tanto confusa. O painel de administração diz que estamos executando o beta, há algum outro lugar onde deveríamos ter olhado? Meu entendimento é que o beta é recomendado para o Discourse com base nos anúncios de lançamento que desencorajam o uso do branch estável.
Quando os 60s foram decididos como um desligamento seguro? Quantas instalações agora são muito maiores do que o normal?
Idealmente, essa espera de 60s deveria ser mais uma espera de loop fechado, com um limite. Parece que o limite deveria ser maior, se agora existem muitas instâncias vulneráveis.
Acho que vi que foi pelo menos em 2016. Mas as coisas mudaram. EDIT: Aqui está um novo commit.
Não acho que muitas em uma instalação padrão, pois tem sido assim quase desde o início.
Uh, sim. Esse é um banco de dados grande. Suspeito que poucas pessoas tenham um banco de dados tão grande que não esteja no RDS ou, pelo menos, em um contêiner separado. Você provavelmente deveria considerar a mudança para uma instalação de 2 contêineres.
Você pode construir um novo contêiner enquanto o antigo continua em execução. Você não precisa desligar o banco de dados para construir um novo contêiner.
Agora existe uma janela de 10 minutos para desligar o postgres, o que deve resolver seu problema atual. Assim que você fizer mais uma reconstrução, você terá os 10 minutos em vez de um.
Ah, esse cara acabou de criar uma instância de dois contêineres totalmente nova e depois restaurou a partir do backup. Definitivamente não faremos isso sem um bom motivo, eu só tive que fazer isso para evitar os requisitos de espaço em disco da atualização do PG13 há cerca de 2 meses.