Modificando o banco de dados dentro de um backup para remover uma tag de chave duplicada para que ele não falhe durante a restauração

Este post é uma versão muito condensada das minhas últimas 24 horas, embora ainda não tenha funcionado, então também espero que alguém poste onde deu errado abaixo.

Minha atualização do Discourse falhou devido a uma chave duplicada, uma das minhas tags está duplicada. Para corrigir o problema da atualização, precisei fazer uma nova instalação do Discourse e, em seguida, carregar meu último backup, mas o recarregamento falha porque ele reclama da chave duplicada. Então, precisei entrar no backup para editar a tag ofensiva para algo diferente.

Por algum motivo, o backup recompactado com o problema da tag duplicada corrigido é significativamente menor do que o backup de onde veio, e falha quando tento restaurá-lo, então algo deu um pouco errado com o processo de recompactação.

1) Localizando Backups: Para localizar seus backups do Discourse, você pode usar o seguinte comando:

sudo find / -name "*.tar.gz"

Isso procurará em seu sistema por todos os arquivos de backup com a extensão “.tar.gz”. Por padrão, ele deve estar dentro do seu contêiner em: shared/backups/default

2) Fazendo uma Cópia: Depois de encontrar o backup com o qual deseja trabalhar, crie uma cópia dele para garantir que você tenha um backup do arquivo original. Use o comando “cp”:

bash

sudo cp /path/to/original_backup.tar.gz /path/to/copy_backup.tar.gz

3) Extraindo a Cópia: Extraia o conteúdo do arquivo de backup copiado usando o comando “tar”:

bash

tar -xzvf /path/to/copy_backup.tar.gz

Isso extrairá os arquivos de backup para um diretório temporário.

4) Editando as Tags no Banco de Dados: Navegue até os arquivos de backup extraídos e abra o arquivo de banco de dados relevante usando um editor de texto. Encontrei um problema com tags duplicadas de “socialmedia”, que impediram a restauração bem-sucedida. Em um banco de dados grande, há muitas instâncias de tags, e provavelmente para a tag específica que você está procurando, então procurei por ‘immutable socialmedia’ usando Ctrl W no Nano, o que me levou diretamente até lá.

sudo nano /path/to/extracted_database.sql

Editei uma instância da tag “socialmedia” para “socialmedia2”, depois fiz uma busca rápida para verificar se ela aparece apenas uma vez agora. Posso corrigir essas tags na seção de administração assim que a restauração for bem-sucedida.

5) Recompactando: Após editar os arquivos de backup, crie um novo arquivo de backup com o conteúdo corrigido. Use o seguinte comando para compactar os arquivos modificados:

tar -czvf /path/to/new_modified_backup.tar.gz /path/to/modified_files_directory

6) Movendo para o Arquivo Correto: Mova o novo arquivo de backup modificado para o diretório apropriado onde os backups são armazenados. O local padrão geralmente é “/shared/backups/default”:

sudo mv /path/to/new_modified_backup.tar.gz /shared/backups/default/

7) Parando e Iniciando Serviços: Antes de restaurar o backup modificado, certifique-se de parar os serviços relevantes para evitar conflitos potenciais durante o processo de restauração. Use o comando “./launcher stop app” para parar o aplicativo Discourse:

./launcher stop app

8) Restaurando o Backup: Para restaurar a partir do backup modificado, use o comando “discourse restore” com o caminho para o novo arquivo de backup:

discourse restore /shared/backups/default/new_modified_backup.tar.gz

Ou você pode fazer isso via /admin em seu site, pois ele agora deve aparecer na seção de backups.

9) Verificando a Restauração: Após a conclusão do processo de restauração, verifiquei se as alterações foram bem-sucedidas verificando o aplicativo Discourse e o banco de dados para garantir que as tags duplicadas de “socialmedia” foram removidas.

10) Iniciando Serviços: Reiniciei os serviços que foram parados anteriormente para trazer o aplicativo Discourse de volta online. Usei o comando “./launcher start app” para iniciar o aplicativo Discourse:

./launcher start app

11) Excluindo Arquivos Temporários e Backups Extras: Após restaurar com sucesso o backup, excluí quaisquer arquivos temporários e backups extras que foram criados durante o processo para liberar espaço em disco. Use o comando “rm” para remover os arquivos:

sudo rm -r /path/to/temporary_directory
sudo rm /path/to/copy_backup.tar.gz
3 curtidas

Por quê?

Por que você não conseguiu corrigir isso ‘online’ reiniciando o aplicativo, entrando no contêiner, entrando no postgres e, em seguida, lidando com a entrada de dados imediatamente?

1 curtida

Não esperava o erro, então já tinha colocado a nova versão do Discourse no meu servidor. O erro de chave duplicada estava no backup e não no aplicativo recém-instalado, mas eu não conseguia restaurar o backup porque ele exigia que o erro fosse corrigido primeiro.

Então, tive que tentar editar a tag dentro do backup.

Mas você viu o erro na atualização?

Da próxima vez, facilite sua vida e corrija no local.

O aplicativo não estava em execução e não consegui recarregá-lo, então atualizei para uma versão nova do Discourse na tentativa de corrigir isso. O que significou que eu não tinha acesso ao banco de dados em nenhum lugar além do backup.

Certamente este é um caso de nicho que postei aqui, a melhor opção teria sido notar o problema e corrigi-lo enquanto eu ainda tinha acesso direto ao banco de dados do aplicativo, mas eu perdi e não consegui encontrar nenhuma outra opção.

1 curtida

Sem problemas. Pelo menos você mostrou que é possível, aprendeu coisas novas e deu uma opção adicional para outras pessoas.

Bom trabalho! :clap:

3 curtidas

Obrigado, embora o arquivo original fosse de 128 MB e o novo seja de 29 MB, então acho que a recompactação no servidor pode ter truncado o arquivo devido ao seu comprimento.

Este processo parece que deve funcionar, mas o arquivo que obtive não pôde ser usado para restaurar meu discourse.

1 curtida

O caminho que você seguiu foi mais arriscado, mas certamente factível? Talvez alguém possa dar um conselho sobre este problema.

Presumivelmente, você pode repetir isso novamente a partir do backup, então…

1 curtida

Este problema foi resolvido? Parece um tutorial, mas o seu site ainda parece estar com problemas.

Talvez você esteja fazendo algo que eu não entendo, mas normalmente você pode simplesmente executar ./launcher start app para iniciar o contêiner antigo, houve algum motivo para você não poder fazer isso?

Em seguida, você pode usar ferramentas Rails ou SQL para corrigir seu banco de dados no contêiner antigo e, em seguida, tentar executar o bootstrap/rebuild novamente.

Ou talvez você tenha migrado o banco de dados além do que seu contêiner antigo poderia suportar.

Eu fiz uma cirurgia semelhante em um backup antes, quando o site que estava sendo restaurado tinha um ano ou mais. Acho que o dump do banco de dados era pequeno o suficiente para que eu pudesse editá-lo no vim.

1 curtida

Obrigado por responder.

Ele se recusou a iniciar, pois estávamos algumas atualizações atrasadas, então atualizei para o Discourse mais recente criando um novo e carregando nosso backup antigo, mas ele rejeitou esse backup devido às chaves duplicadas.

Ou talvez você tenha migrado o banco de dados para além do que seu contêiner antigo poderia lidar.

Sim, provavelmente isso. É um pouco confuso exatamente o que fiz agora, mas atualizei algumas coisas independentemente com base em conselhos de solução de problemas aqui. Uma delas foi obter a versão mais recente do PostgreSQL.

Consegui editá-lo no vim.

Consegui editar no Nano, e tudo parecia bom, mas o arquivo recompactado era muito pequeno, então algo deu errado em algum lugar… talvez eu não tenha conseguido editá-lo no Nano. Pareceu ter funcionado na época.

Eu esperava que alguém visse um erro nele e me corrigisse, para que se tornasse um guia de ‘como fazer’.

O que eu olharia em seguida:

  • Refaça toda a descompactação. Compacte-a sem alterações. Verifique se o tamanho do zip é o mesmo de antes. Se não for, talvez você não esteja compactando com as mesmas opções?

  • Descompacte novamente, verifique o tamanho do arquivo que você está editando. Edite-o, salve-o, confirme se o tamanho não mudou significativamente.

1 curtida

Uma pequena atualização. Outra pessoa da minha equipe estava trabalhando nisso na semana passada, mas uma solução não surgiu, então tentei novamente, desta vez editando o banco de dados no meu sistema local.

O que eu fiz:

  1. baixei um backup antigo que quero restaurar
  2. descompactei os arquivos com 7zip
  3. abri dump.sql com o Visual Studio Code
  4. encontrei as tags duplicadas diretamente no banco de dados.
  5. encontrei o que parecia ser a listagem de tags pesquisando usando ’ ’ em volta da tag. No meu caso, ‘socialmedia’. As tags parecem ser a 2ª e 3ª de baixo das instâncias encontradas.

  1. editei uma para ler

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Recompactei o arquivo dump.sql no 7zip
  • Adicionar ao arquivo
  • Formato do arquivo .gzip
  1. Recompactei o arquivo de backup principal
  • Adicionar ao arquivo
  • Formato do arquivo .tar (gzip ainda não está disponível)
  1. Agora você deve ver um arquivo de backup .tar corrigido e compactado

  2. Compacte o arquivo .tar no 7zip para criar um arquivo .tar.gz, para corresponder ao formato usado pelo Discourse

  • Adicionar ao arquivo
  • Formato do arquivo .gzip
  1. Carregue em backups e restaure através da seção de administração

Neste ponto, encontrei uma mensagem de erro:

Extraindo arquivo dump…
[2023-08-08 15:09:15] EXCEPTION: No such file or directory @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Alguém tem alguma ideia do que perdi no processo acima?
A única coisa em que consigo pensar é que o caminho que ele está procurando usa a data de hoje e não a data do backup (estou escrevendo isso em 08-08-2023).

Este é um acompanhamento da minha postagem anterior aqui. Estou postando novamente para que seja mais fácil de encontrar para qualquer outra pessoa que faça isso no futuro, se funcionar.

O que fiz para editar o DB no meu laptop:

  1. baixei o backup antigo que quero restaurar da seção de administração
  2. descompactei os arquivos com 7zip
  3. abri o dump.sql com o visual studio code
  4. encontrei as tags duplicadas diretamente no DB.
  5. encontrei o que parecia ser a listagem de tags pesquisando usando ’ ’ em volta da tag. No meu caso, ‘socialmedia’. As tags parecem ser a 2ª e 3ª de baixo para cima das instâncias encontradas.

  1. editei uma para ler

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Compactei novamente o arquivo dump.sql no 7zip
  • Adicionar ao arquivo
  • Formato do arquivo .gzip
  1. Compactei novamente o arquivo de backup principal
  • Adicionar ao arquivo
  • Formato do arquivo .tar (gzip ainda não está disponível)
  1. Agora você deve ver um arquivo de backup .tar compactado e corrigido

  2. Compacte o arquivo .tar no 7zip para criar um arquivo .tar.gz, para corresponder ao formato usado pelo Discourse

  • Adicionar ao arquivo
  • Formato do arquivo .gzip
  1. Carregue em backups e restaure através da seção de administração

Neste ponto, recebi uma mensagem de erro:

Extraindo o arquivo dump…
[2023-08-08 15:09:15] EXCEPTION: No such file or directory @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Alguém tem alguma ideia do que perdi no processo acima?
A única coisa em que consigo pensar é que o caminho que ele está procurando usa a data de hoje e não a data do backup (estou escrevendo isso em 08-08-2023).

1 curtida

Eu acho que talvez o nome exato de um arquivo de backup seja importante: nome do fórum, data e carimbo de data/hora, identificador de versão. Portanto, se descompactar, modificar e reempacotar, sugiro reconstruir com o mesmo nome do original. Mas mantenha o original seguro, é claro.

1 curtida

Eu combinei as postagens do novo tópico nesta, pois parece que manter este problema agrupado em um só lugar facilitará muito o acompanhamento para futuros viajantes. :+1:

1 curtida

Obrigado @Ed_S, mantive o nome original, pois li em outro lugar que era importante. Minha pergunta acima é sobre por que a ferramenta de restauração de backup estava procurando e não encontrando: /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

que é a data em que eu estava fazendo a restauração.

1 curtida

Ah, desculpe. Isso parece estranho. Pode ser que o diretório temporário seja esperado ter o nome de acordo com a data de hoje, mas não parece bom que o arquivo de dump sql não seja encontrado.

Se você listar o conteúdo do arquivo tar, você vê esse nome de arquivo lá? No meu caso

root@ubuntu-2gb-nbg1-1:/var/discourse/shared/standalone/backups/default# tar vtfz forumname-2023-08-03-HHMMSS-v2023mmddhhmmss.tar.gz dump.sql.gz | head
-rw-r--r-- discourse/www-data 16336925 2023-08-03 05:31 dump.sql.gz
1 curtida

Obrigado Ed, esse arquivo não existia. Desculpe pelo atraso, estive offline por um tempo.

Não há um arquivo com o nome correto lá, então acabei de tentar criar um arquivo vazio manualmente:

sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/

Mas toda vez que clico em restaurar, ele procura por um arquivo ligeiramente diferente (os últimos 6 dígitos). Presumo que esteja procurando por uma pasta gerada por um timestamp, então cada vez que clico no botão de restaurar, a pasta que ele procura mudou.

Suspeito que algo esteja dando errado na sua etapa 10, onde você cria o arquivo tar. Você consegue ver? Você pode usar file para descrevê-lo? Você pode listar o conteúdo com tar tvfz?

1 curtida