Por favor, você pode nos orientar sobre qual arquivo devemos editar no backup tar?
Existe um dump.sql compactado dentro dos arquivos. Você precisa modificá-lo e depois recompactar a versão modificada de volta. Eu também resolvi meus outros problemas modificando-o — removi alguns campos personalizados problemáticos que estavam causando travamentos após o login.
Obrigado.
Vou tentar baixar o backup, descompactá-lo e alterar esse arquivo seguindo suas instruções.
É bastante assustador ter que fazer tudo isso para restaurar um backup.
Suponho que seja um bug da nova versão.
Mas backup e restauração são pilares de um plano de recuperação de desastres.
Eles devem ser o mais robustos possível, e um bug nesses processos tem grande impacto.
1 curtida
Bem, consegui fazer a restauração sem alterar nada no arquivo de backup.
Tentei várias vezes e, estranhamente, em uma delas a restauração ocorreu sem erros.
Fui expulso do Discourse e não funcionou até que eu criasse um aplicativo de reconstrução do launcher.
Mas agora está funcionando corretamente.
Um problema estranho.
Isso ainda está me causando problemas ao restaurar meu fórum a partir do backup. Já se passaram várias semanas e a funcionalidade de restauração a partir do backup parece ainda estar quebrada.
Há alguma correção para isso?
Pelo que consigo ver, alterno entre atualizar, verificar a formatação das tabelas, garantir que tudo seja semelhante entre a fonte e o host, e observar o processo falhar várias vezes. Isso pode ou não funcionar sem algumas edições menores no banco de dados.
Já migrei com sucesso 2 de 3 sites e sou forçado a dedicar menos de uma hora por dia a isso, para manter a sanidade. Comecei a conversar com os clientes sobre os problemas que isso pode causar no futuro em situações semelhantes. encolhe os ombros
Eu simplesmente insisto em restaurar e consegui fazê-lo funcionar.
O erro reclama de uma coluna que não existe na tabela de perfil do usuário.
Mas deve ser um erro de tempo limite ou algo assim no lado do banco de dados, talvez um bug no lado do PostgreSQL. Se a coluna não estiver lá, ela não é criada automaticamente quando você insiste na restauração.
Jaromir diz que alterar o script resolve o problema.
Nenhum dos desenvolvedores do Discourse aqui parece ter se preocupado com esse problema, mas é um erro estranho e muito perturbador, pois afeta seu plano de recuperação de desastres.
Talvez o tópico tenha passado despercebido entre os outros.
Isso não passou despercebido. Será a primeira coisa que vou investigar amanhã.
E estou começando a trabalhar na melhoria de backups e restaurações, porque ninguém deveria precisar se preocupar com essas coisas em caso de desastre ou quando quiser simplesmente migrar para um novo servidor.
11 curtidas
Ótimo. Obrigado.
Fico feliz em saber disso.
Obrigado, Gerhard. Não sei se isso ainda é relevante para você, mas também estou com problemas em um site que usa o PG 11 no GCP. Vale a pena verificar isso, pois pode afetar a futura migração para o PG 12, que, segundo entendi, deve ocorrer no final deste outono.
Acabei de atualizar duas instâncias que compartilham um bucket de backup no S3. Executei um backup em uma delas e tentei restaurar na outra, mas obtive o seguinte erro:
Nenhuma migração com o número de versão 20191007140446.
PostgreSQL 11 e 12 não são atualmente suportados.
4 curtidas
Ok, instalei a versão mais recente do Discourse (tests-passed) em um droplet e a restauração de backups (incluindo uploads, sem usar S3 para uploads) funcionou sem problemas.
Se você ainda estiver enfrentando problemas durante uma restauração, faça o seguinte:
-
Reconstrua o contêiner:
cd /var/discourse git pull ./launcher rebuild app -
Restaure o backup via interface web ou linha de comando:
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
Se não funcionar, por favor, poste o número da versão do arquivo de backup que você está tentando restaurar, bem como a mensagem de erro que você vê durante a restauração.
6 curtidas
Ambos os sites estão na versão 2.4.0.beta6 (8fc0cc9aaa). Os backups (mas não os uploads) estão no S3.
discourse restore retorna
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2019-10-10-211121 exists...
Downloading archive to tmp directory...
Unzipping archive, this may take a while...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
Claro, e acho que esse site ficará satisfeito com backups diretos do banco de dados no GCP de qualquer maneira, mas em algum momento o Sam disse que estava executando o PG 11 em seu site de desenvolvimento e que teria interesse em saber de problemas com o PG11.
@pfaffman Por favor, aumente a configuração do site decompressed_file_max_size_mb (ela está oculta). O padrão está atualmente definido em 1 GB.
Tenho uma PR pronta para aumentar o padrão para 100 GB, mas ela ainda não foi mesclada:
7 curtidas
Obrigado, @Roman. Bem, isso resolveu o problema.
Mas agora tenho vários invalid command \N (e eles encheram o buffer antes que eu pudesse ver o que veio antes), mas talvez
ERROR: syntax error at or near "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
seja o que você precisa saber.
Sim, acredito que isso seja causado pelo PG11.
2 curtidas
Se fosse a instância pg11, eu concordaria! Mas esta é uma instalação padrão com 2 contêineres.
Espere! Há uma incompatibilidade de versão.
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
A que estou restaurando é a 10.9! Aposto que é isso. (Acho que a pg11 falha de forma semelhante, mas lá estou tentando restaurar na mesma instância).
Vou atualizar os contêineres de dados amanhã e te aviso. Obrigado pela ajuda.
3 curtidas
Bem, atualizei ambos para a 10.10 (usando os modelos de dados padrão), mas ainda obtive o problema de invalid command.
Quando os erros de invalid command começaram, forcei a finalização do script de restauração. Novas tentativas de restauração (para obter o primeiro erro antes das mensagens de invalid command) resultaram em:
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "theme_fields" does not exist
Em seguida, executei um rake db:migrate em ambas as instâncias, fiz um novo backup e a restauração foi bem-sucedida. Talvez uma migração tenha sido perdida em algum momento?
(após alterar a configuração mencionada acima—aqui estão as instruções completas para quem possa precisar delas no curto período antes de se tornarem desnecessárias)
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
1 curtida
Acabei de ter mais uma falha. Neste caso, ambos são 2.4.0.beta6 (um é 2c011252f1, o outro pode ser um pouco mais recente).
Estou restaurando via S3. Testei tanto com quanto sem uploads. Ambos pareciam estar funcionando e então falharam assim:
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: linha 2: 3232 Morto RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
Essa é a única mensagem que você está recebendo?
E se você tentar remover qualquer dependência do S3 e copiar o arquivo de backup para o local primeiro?
@pfaffman, seria bom saber que os dois (ou três) problemas de restauração que você postou neste tópico não são ocorrências do bug que este tópico tratava originalmente (o problema PG::UndefinedColumn: ERROR). Você pode considerar abrir novos tópicos para esses, já que são claramente problemas diferentes.
4 curtidas