andy@ubuntu-s-1vcpu-1gb-ams3-01:/var/discourse/shared/standalone/backups/default$ file public-happiness-2023-07-25-033857-v20220628031850.tar.gz
public-happiness-2023-07-25-033857-v20220628031850.tar.gz: gzip compressed data, was "public-happiness-2023-07-25-033857-v20220628031850.tar", last modified: Tue Aug 8 14:53:40 2023, max speed, from FAT filesystem (MS-DOS, OS/2, NT)
O conteúdo completo do arquivo parece bom, embora seja difícil dizer, pois é muita informação: Hastebin
Eu acho que tem a ver com os caminhos dos arquivos. Dê uma olhada em
Hmm. Isso pode não ser o problema. Eu geralmente não confio no 7zip para criar um arquivo tar compatível, mas isso pode ser irracional.
-h, --dereference
Follow symlinks; archive and dump the files they point to.
A resposta pode estar no arquivo acima. Na verdade, provavelmente está em outro arquivo no mesmo diretório.
Obrigado - conteúdo correto, mas com nomes errados, eu acho. Daí o problema.
Você tem
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 public-happiness-2023-07-25-033857-v20220628031850/dump.sql.gz
mas o original e qualquer backup não modificado teriam
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 dump.sql.gz
Edição: então você precisa usar o 7zip um pouco diferente na construção desse arquivo tar.gz.
Obrigado por toda a ajuda. Descompactei os arquivos, editei a tag duplicada novamente e depois a compactei com muito cuidado, prestando atenção extra ao nome do arquivo, e houve progresso!
Agora, ao restaurar, vejo esta mensagem de erro, que parece ser muito mais comum:
[2023-08-25 15:25:21] CREATE INDEX
[2023-08-25 15:25:21] ERROR: could not create unique index "index_tags_on_lower_name"
[2023-08-25 15:25:21] DETAIL: Key (lower(name::text))=(socialmedia) is duplicated.
[2023-08-25 15:25:21] EXCEPTION: psql failed: DETAIL: Key (lower(name::text))=(socialmedia) is duplicated.
Eu apostaria que isso significa que alterei a tag com sucesso, mas ainda existem algumas ocorrências da tag em postagens no meu banco de dados. O número do tag_id indica que deveria haver uma tag chamada socialmedia, mas em vez disso, ele está encontrando uma tag chamada socialmedia2, o que está causando um conflito.
esta postagem e esta outra discutem correções, mas como só tenho acesso ao meu backup editando diretamente o código na minha máquina local, não consigo usar as ferramentas do mysql para ajudar na limpeza.
Felizmente, no meu banco de dados, tenho apenas 38 instâncias de 'socialmedia' (em oposição a mais de 50.000 ocorrências de socialmedia). Assumindo que eu estava correto ao alterar a linha 395421, como mostrei na captura de tela acima, então não consigo ver como dizer quais das restantes estão vinculadas à tag ‘socialmedia’ e quais à tag que editei para ‘socialmedia2’.
Aqui está um exemplo de uma postagem relativamente curta usando a tag socialmedia
9488 '/groups/communitybuilders':86 '/groups/socialmedia':84 '/groups/webdev':89 '1st':117 '2022':131 '6':125 'activ':61 'banner':113 'btw':143 'close':169 'comment':21 'communiti':47 'communitybuild':87 'concept':4A 'especi':28 'event':119 'excit':164 'feedback':8B 'final':166 'get':38,133 'github':94 'grow':6A,142 'hack':127 'hard':156 'help':96 'homepag':151 'host':124 'improv':11B 'join':71,106 'launch':41,118,126 'like':128 'link':110 'live':140,175 'lot':27 'love':1A,67 'marvelxi':152 'mean':25 'media':51 'member':62 'mention':93 'move':45 'much':15 'new':150 'one':72,107 'onto':53 'plan':121 'platform':7B,43,139 'pleas':5A 'project':137 'promot':97 're':33,36,56,161 'readi':39,172 'rhorho358':23 'right':63 'see':100,167 'site':176 'slight':76,177,179 'small':58 'smile':77,178,180 'social':50 'socialmedia':85 'stage':31 'suggest':10B 'sure':79 'take':17 'team':59,75,103 'thank':12 'think':147 'time':19 'use':108 'webdev':90 'websit':3A 'whether':80 'work':155 'would':66,82 Obrigado por dedicar tempo para comentar aqui @R, significa muito, especialmente no st... tem trabalhado duro nisso e todos nós estamos muito animados para finalmente vê-lo quase pronto no site ao vivo :slight_smile: :slight_smile: en_GB 4 f
No entanto, posso estar no caminho errado, pois isso parece ter mais tags no início do que um usuário provavelmente usaria em uma postagem. Também é possível que ‘socialmedia’ não seja uma tag usada na postagem acima, embora devesse ser.
Eu restauraria o banco de dados manualmente e tentaria adicionar os índices e corrigir os problemas do banco de dados em vez de um arquivo de texto, mas isso também é difícil.
Não acho que essa seja a conclusão imediata que você pode/deve tirar. O problema deve ser simples:
O motivo pelo qual o índice não será criado é que você tem pelo menos duas entradas na tabela tags que resultam na mesma coisa quando você pega a versão em minúsculas do nome delas. É isso que a mensagem de erro está dizendo.
Portanto, acho que você ainda precisa encontrar as entradas relacionadas nessa única tabela que entram em conflito ao passar por essa transformação.
Antes de excluir os duplicados, anote seus IDs porque você também precisará excluir as linhas relacionadas da tabela topic_tags (algo que você poderia ter resolvido rapidamente se tivesse realizado toda essa manutenção online simplesmente reiniciando o contêiner, em vez de destruir a instância!!).
Nosso site está de volta! Obrigado a todos pela ajuda.
Parece que eu tinha resolvido isso dias atrás, mas fui descuidado ao ler a mensagem de erro. Havia duas tags duplicadas, ‘socialmedia’ e ‘social-media’. Depois de corrigir a primeira, não percebi que a mensagem de erro havia mudado, dada a semelhança entre as duas tags duplicadas.
Aqui estão os processos para corrigir esses dois erros:
1. Encontrando a tabela de tags e a tag duplicada
Baixe o backup para o seu sistema operacional. Este guia é para Windows, mas o processo será praticamente o mesmo no Linux.
Extraia todas as pastas compactadas, o que deve resultar em um arquivo dump.sql e uma pasta uploads.
Abra o arquivo dump.sql com um editor de texto; eu usei o Visual Studio Code.
Procure por “COPY public.tags” para localizar a tabela de tags. Ela deve estar perto do final e parecer com isto:
Navegue manualmente ou copie e cole sua tabela de tags em um documento separado onde você possa usar a função de pesquisa para encontrar sua tag duplicada.
Salve seu arquivo dump.sql corrigido como dump.sql.
2. A ordem e os nomes dos arquivos e pastas precisam ser perfeitos na nova compactação.
Após a extração, você deve ter um arquivo dump.sql e uma pasta uploads.
Clique com o botão direito em dump.sql. Selecione 7zip e ‘add to archive’.
Selecione gzip como formato de arquivo, mantendo o mesmo nome do arquivo.
Selecione o novo arquivo dump.sql.gz e o arquivo uploads, então clique com o botão direito > 7zip > add to archive > archive format: tar. Certifique-se de que o nome do arquivo seja exatamente o mesmo do backup original; ele deve se parecer com algo assim: ‘public-happiness-2023-07-25-033857-v20220628031850’.
Selecione seu novo arquivo .tar > 7zip > add to archive > archive format: gzip. Certifique-se de que o nome do arquivo seja exatamente o mesmo do backup original; ele deve se parecer com algo assim: ‘public-happiness-2023-07-25-033857-v20220628031850’.
Seu resultado final deve ser um arquivo .tar.gz com o mesmo nome do seu backup original.
Faça o upload para a área de administração e restaure seu backup.
Há mais um local onde a tag é/pode ser repetida e esse é a tabela de dados de pesquisa:
COPY public.tag_search_data (tag_id, search_data, raw_data, locale, version) FROM stdin;
Não tenho certeza se isso também precisa ser corrigido ou não.
Fico feliz que você finalmente tenha consertado!
