Falha no Bootstrap, por favor ajude :(

Tentando atualizar e o Discourse não está conseguindo inicializar. Alguém pode orientar quais passos devo seguir para colocar meu site de volta no ar? Executei o discourse-doctor, mas ele também não conseguiu reconstruir. Abaixo, coloco os logs da minha (terceira?) tentativa:

 I, [2020-04-11T13:05:40.743940 #1]  INFO -- : Carregando --stdin
I, [2020-04-11T13:05:40.750131 #1]  INFO -- : 
I, [2020-04-11T13:05:40.800464 #1]  INFO -- : Gerando locais (isso pode levar um tempo)...
Geração concluída.

I, [2020-04-11T13:05:40.800750 #1]  INFO -- : 
I, [2020-04-11T13:05:40.804473 #1]  INFO -- : 
I, [2020-04-11T13:05:40.804720 #1]  INFO -- : 
I, [2020-04-11T13:05:40.809297 #1]  INFO -- : 
I, [2020-04-11T13:05:40.809573 #1]  INFO -- : 
I, [2020-04-11T13:05:40.813859 #1]  INFO -- : 
I, [2020-04-11T13:05:40.814113 #1]  INFO -- : 
I, [2020-04-11T13:05:40.818749 #1]  INFO -- : 
I, [2020-04-11T13:05:40.819005 #1]  INFO -- : 
I, [2020-04-11T13:05:40.823141 #1]  INFO -- : 
I, [2020-04-11T13:05:40.823401 #1]  INFO -- : 
2020/04/11 13:05:40 socat[26] E connect(6, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): Conexão recusada
I, [2020-04-11T13:05:40.831215 #1]  INFO -- : 
I, [2020-04-11T13:05:40.831436 #1]  INFO -- : 
I, [2020-04-11T13:05:40.837350 #1]  INFO -- : 
I, [2020-04-11T13:05:40.837549 #1]  INFO -- : 
I, [2020-04-11T13:05:40.843241 #1]  INFO -- : 
I, [2020-04-11T13:05:40.843486 #1]  INFO -- : 
I, [2020-04-11T13:05:40.848311 #1]  INFO -- : 
I, [2020-04-11T13:05:40.848643 #1]  INFO -- : 
I, [2020-04-11T13:05:40.853421 #1]  INFO -- : 
I, [2020-04-11T13:05:40.863897 #1]  INFO -- : Arquivo > /etc/service/postgres/run  chmod: +x  chown: 
I, [2020-04-11T13:05:40.873965 #1]  INFO -- : Arquivo > /etc/service/postgres/log/run  chmod: +x  chown: 
I, [2020-04-11T13:05:40.884485 #1]  INFO -- : Arquivo > /etc/runit/3.d/99-postgres  chmod: +x  chown: 
I, [2020-04-11T13:05:40.895036 #1]  INFO -- : Arquivo > /root/upgrade_postgres  chmod: +x  chown: 
I, [2020-04-11T13:05:40.895478 #1]  INFO -- : 
I, [2020-04-11T13:06:09.192272 #1]  INFO -- : 
I, [2020-04-11T13:06:09.192593 #1]  INFO -- : 
I, [2020-04-11T13:06:09.197837 #1]  INFO -- : 
I, [2020-04-11T13:06:09.197992 #1]  INFO -- : 
I, [2020-04-11T13:06:09.228153 #1]  INFO -- : 
I, [2020-04-11T13:06:09.228375 #1]  INFO -- : 
I, [2020-04-11T13:06:09.233425 #1]  INFO -- : 
I, [2020-04-11T13:06:09.233760 #1]  INFO -- : 
I, [2020-04-11T13:06:09.243357 #1]  INFO -- : 
I, [2020-04-11T13:06:09.243596 #1]  INFO -- : 
I, [2020-04-11T13:06:09.249007 #1]  INFO -- : 
I, [2020-04-11T13:06:09.249495 #1]  INFO -- : Substituindo data_directory = '/var/lib/postgresql/10/main' por data_directory = '/shared/postgres_data' em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.272106 #1]  INFO -- : Substituindo (?-mix:#?listen_addresses *=.*) por listen_addresses = '*' em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.272853 #1]  INFO -- : Substituindo (?-mix:#?synchronous_commit *=.*) por synchronous_commit = $db_synchronous_commit em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.273496 #1]  INFO -- : Substituindo (?-mix:#?shared_buffers *=.*) por shared_buffers = $db_shared_buffers em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.274139 #1]  INFO -- : Substituindo (?-mix:#?work_mem *=.*) por work_mem = $db_work_mem em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.274757 #1]  INFO -- : Substituindo (?-mix:#?default_text_search_config *=.*) por default_text_search_config = '$db_default_text_search_config' em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.275288 #1]  INFO -- : 
I, [2020-04-11T13:06:09.282029 #1]  INFO -- : 
I, [2020-04-11T13:06:09.282556 #1]  INFO -- : Substituindo (?-mix:#?max_wal_senders *=.*) por max_wal_senders = $db_max_wal_senders em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.330309 #1]  INFO -- : Substituindo (?-mix:#?wal_level *=.*) por wal_level = $db_wal_level em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.331016 #1]  INFO -- : Substituindo (?-mix:#?checkpoint_segments *=.*) por checkpoint_segments = $db_checkpoint_segments em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.331655 #1]  INFO -- : Substituindo (?-mix:#?logging_collector *=.*) por logging_collector = $db_logging_collector em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.332347 #1]  INFO -- : Substituindo (?-mix:#?log_min_duration_statement *=.*) por log_min_duration_statement = $db_log_min_duration_statement em /etc/postgresql/10/main/postgresql.conf
I, [2020-04-11T13:06:09.333020 #1]  INFO -- : Substituindo (?-mix:^#local +replication +postgres +peer$) por local replication postgres  peer em /etc/postgresql/10/main/pg_hba.conf
I, [2020-04-11T13:06:09.333660 #1]  INFO -- : Substituindo (?-mix:^host.*all.*all.*127.*$) por host all all 0.0.0.0/0 md5 em /etc/postgresql/10/main/pg_hba.conf
I, [2020-04-11T13:06:09.334205 #1]  INFO -- : 
I, [2020-04-11T13:06:09.338659 #1]  INFO -- : 
2020-04-11 13:06:09.481 UTC [49] LOG:  ouvindo no endereço IPv4 "0.0.0.0", porta 5432
2020-04-11 13:06:09.482 UTC [49] LOG:  ouvindo no endereço IPv6 "::", porta 5432
2020-04-11 13:06:09.544 UTC [49] LOG:  ouvindo no socket Unix "/var/run/postgresql/.s.PGSQL.5432"
2020-04-11 13:06:10.813 UTC [52] LOG:  o desligamento do sistema de banco de dados foi interrompido; última execução conhecida em 2020-04-11 12:42:48 UTC
2020-04-11 13:06:12.356 UTC [52] LOG:  o sistema de banco de dados não foi desligado corretamente; recuperação automática em andamento
2020-04-11 13:06:12.416 UTC [52] LOG:  redo começa em 84/BD1A85B0
2020-04-11 13:06:12.446 UTC [52] LOG:  registro inválido no comprimento em 84/BD7B3570: esperado 24, obtido 0
2020-04-11 13:06:12.446 UTC [52] LOG:  redo concluído em 84/BD7B3530
2020-04-11 13:06:12.446 UTC [52] LOG:  última transação concluída foi no tempo de log 2020-04-11 11:53:53.069757+00
I, [2020-04-11T13:06:14.343128 #1]  INFO -- : 
I, [2020-04-11T13:06:14.343449 #1]  INFO -- : 
2020-04-11 13:06:14.409 UTC [56] postgres@postgres FATAL:  o sistema de banco de dados está iniciando
2020-04-11 13:06:14.411 UTC [57] postgres@template1 FATAL:  o sistema de banco de dados está iniciando
createdb: não foi possível conectar ao banco de dados template1: FATAL:  o sistema de banco de dados está iniciando
I, [2020-04-11T13:06:14.413548 #1]  INFO -- : 
I, [2020-04-11T13:06:14.413822 #1]  INFO -- : 
2020-04-11 13:06:14.493 UTC [68] postgres@discourse FATAL:  o sistema de banco de dados está iniciando
psql: FATAL:  o sistema de banco de dados está iniciando
I, [2020-04-11T13:06:14.495917 #1]  INFO -- : 
I, [2020-04-11T13:06:14.496250 #1]  INFO -- : 
2020-04-11 13:06:14.574 UTC [79] postgres@discourse FATAL:  o sistema de banco de dados está iniciando
psql: FATAL:  o sistema de banco de dados está iniciando
I, [2020-04-11T13:06:14.576284 #1]  INFO -- : 
I, [2020-04-11T13:06:14.576674 #1]  INFO -- : 
2020-04-11 13:06:14.655 UTC [90] postgres@discourse FATAL:  o sistema de banco de dados está iniciando
psql: FATAL:  o sistema de banco de dados está iniciando
I, [2020-04-11T13:06:14.658074 #1]  INFO -- : 
I, [2020-04-11T13:06:14.658635 #1]  INFO -- : Terminando processos assíncronos
I, [2020-04-11T13:06:14.658722 #1]  INFO -- : Enviando INT para HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main pid: 49
2020-04-11 13:06:14.658 UTC [49] LOG:  recebida solicitação de desligamento rápido
I, [2020-04-11T13:06:24.659800 #1]  INFO -- : HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main pid:49 não terminou corretamente, forçando término!


FALHA
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' falhou com retorno #<Process::Status: pid 80 exit 2>
Localização da falha: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec falhou com os parâmetros "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
3956a617d80571dd1ef87fcf7d23a319190bd909477e703ccb22cb25d0e137c8
** FALHA NA INICIALIZAÇÃO ** por favor, role para cima e procure por mensagens de erro anteriores; pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.

Parece que seu banco de dados está corrompido. Você tem espaço suficiente no disco? (Duvido que esse seja o problema, mas seria ótimo se fosse.)

A solução mais fácil provavelmente é excluir o diretório do banco de dados, o que criará um novo banco de dados. Em seguida, você pode restaurar a partir do seu backup mais recente.

Para dar uma atualização agora que já estou fora do calor do momento — reiniciar o servidor permitiu que o aplicativo fosse recriado. Essa foi uma sugestão do @merefield que encontrei em outro lugar por aqui e apliquei como uma solução de último recurso.

Então, o que quer que o Postgres estivesse reclamando continua sendo um mistério para mim. Agora tenho problemas novos, mas menos críticos. Pelo lado positivo, não precisei destruir meu banco de dados grande.

@pfaffman, temos uma quantidade considerável de armazenamento; estamos muito longe de atingir o limite.

Obrigado por todos os comentários. Espero que minha experiência dolorosa ajude alguém por aí :slight_smile:

Olá,

recebemos a mesma mensagem em uma reconstrução para uma atualização de versão…

… e pensamos que estava acontecendo conosco também – pela primeira vez –

… e hesitantes procuramos o diretório de backup ;]. Um backup recente estava lá, então relaxamos um pouco.

Também queríamos compartilhar que, embora não tenhamos reiniciado o servidor, esperamos um pouco, falhamos na reconstrução pela segunda vez com a mesma mensagem de erro invalid record length at, mas agora o processo de atualização parece estar funcionando ao tentar pela terceira vez. O servidor tem espaço em disco suficiente, mas está atualmente um pouco sobrecarregado em termos de I/O.

Talvez isso ajude outros que possam estar passando pela mesma situação. Com base nessa experiência, aconselhamos a) mitigar o consumo excessivo de recursos no sistema host antes de tentar outra reconstrução e b) não desistir muito cedo.

Com os melhores cumprimentos,
Andreas.

Bem, diz que uma recuperação está em andamento, então talvez você possa deixá-la se recuperar? Acho que você talvez reiniciaria o contêiner antigo para permitir que isso acontecesse.

Isso foi resolvido?

Tudo funcionou bem e a atualização foi concluída sem erros na terceira tentativa. Obrigado e feliz ano novo!

Problemas com aparência semelhante vistos anteriormente foram resolvidos ajustando um valor de tempo limite:

Ou esperando: