Então, tenho um backup do Discourse do nosso servidor inicial e estamos tentando mover o sistema para um novo sistema.
Infelizmente, existem dois problemas:
Durante a restauração, ele diz que 71 de 1073 uploads não foram migrados para o S3 e, portanto, falha durante o processo de restauração.
Tentando corrigir isso na instância principal reprocessando, etc., as postagens, ele indica que alguns uploads ainda não foram migrados para o S3, mesmo quando tento usar o mecanismo uploads:migrate_to_s3 do rake.
Existe alguma maneira de obter informações detalhadas do migrate_to_s3 sobre quais uploads não foram migrados, para que eu possa corrigi-los manualmente? É possível também que eles estejam se referindo a um repositório S3 morto/falho de onde estávamos fazendo o upload inicialmente, exceto que as coisas explodiram naquele ponto e simplesmente mudamos os mecanismos S3 (para MinIO, é claro), e ainda havia coisas antigas no lado AWS S3. O que eu não acho que posso migrar facilmente para nossa instância MinIO.
Alternativamente, existe uma maneira de desabilitar o verificador de uploads no S3 do mecanismo de restauração porque eu já forcei a migração dos uploads?
OK, então, descobri depois de mergulhar fundo no banco de dados. Parece que sobraram (71 uploads) do ambiente S3 original, que já não existe há muito tempo (ou, neste caso, um ambiente S3 disponível, mas não usado principalmente, porque não seria econômico).
Acabei fazendo o seguinte:
Do Servidor de Origem:
./launcher enter app
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'
(substitua o ExpectedS3DomainGoesHere pelo URL real que você usa para sua configuração S3)
Isso obterá os URLs para você trabalhar, porque precisamos fazer algumas coisas.
Onde os URLs são de buckets mais antigos em URLs diferentes, use o cliente Amazon S3 (ou o cliente para seu backend de armazenamento S3) e:
a. Sincronize os buckets com URLs inesperados, se disponíveis, para o armazenamento local.
b. Sincronize os itens do Local para o novo Bucket.
discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DB
Embora tenha sido sugerido aqui usar DbHelper.remap, a função remap do discourse funcionou bem.
Certifique-se de que os dados foram migrados. rails uploads:migrate_to_s3
Hora de rebater! rails posts:rebake
Faça backup do site novamente na máquina/servidor de ‘origem’. Baixe essa última atualização.
Do Novo Servidor de Destino:
Configure o Discourse como esperado, copie o app.yml e outros do servidor de origem para o novo servidor em /var/discourse/containers/ para garantir que a reconstrução atinja os plugins corretos, etc., necessários.
Certifique-se de comentar quaisquer entradas DISCOURSE_BACKUP_LOCATION: s3 no app.yml, se você estiver trabalhando com cópias de backup locais. Tive alguns problemas com o S3 sendo estranho com arquivos de backup sendo truncados, então optei pela abordagem local para uma restauração.
Isso foi doloroso para eu resolver, mas foi resolvido depois que mergulhei fundo na tabela de uploads no banco de dados. MAS, isso parece ter funcionado, então…
O que muitas vezes funciona nessas situações é desabilitar temporariamente os uploads do s3 na instância original antes de fazer um backup. Após restaurar, você pode habilitar o s3 novamente.