Após ter várias interrupções e problemas com nosso provedor S3 (vultr), pensei que seria melhor abordar os uploads do site de forma diferente. O VPS deles tem sido confiável, mas o armazenamento de objetos falha com muito mais frequência. Também estou considerando migrar para meu próprio hardware novo para economizar $$$, mas o primeiro obstáculo parece ser a falta de uma maneira de migrar de S3 para local. Vejo que a tarefa rake que se destinava a servir a esse propósito desapareceu, e a operação recomendada de backup/restauração parece ter problemas do meu lado.
Atualmente, tenho um servidor operando em forum.tld e o novo hardware de destino está rodando em forum2.tld. Habilitei as configurações ocultas do site para fazer backup dos uploads e executei a tarefa de backup.
Quando executo a tarefa de backup com S3 habilitado, realmente pareço capturar todos os uploads relevantes, mas a restauração desse backup falha (e parece usar S3 de qualquer maneira).
Quando desabilito o S3 antes de executar o backup e a restauração, ele restaura com sucesso, mas obviamente os uploads do S3 ficam quebrados. Posso mesclar uploads do outro backup, mas simplesmente fazer um rebake não parece atualizar corretamente as postagens.
Tenho sorte de ter o segundo servidor para tentar todas as coisas estúpidas, então, se alguém tiver uma ideia estúpida, estou mais do que disposto a considerá-la.
Eu simplesmente não vejo um bom caminho para se livrar do S3 depois de implementá-lo. Tenho postagens mais antigas de quando migramos para a AWS e de volta para a vultr que quebraram e desisti de tentar entender isso. Parece que todos os uploads são hasheados com sha1 e renomeados, depois adicionados a algum mapeamento separado do banco de dados. Esse processo parece ser apenas um negócio de mão única. Talvez um desenvolvedor possa dar uma dica sobre como gerar esse mapeamento?
Existe uma maneira de fazer isso sem uma operação de backup/restauração?
Qual é o caminho esperado/pretendido para alguém migrar do S3 atualmente?
To add more context to this, I tried restoring a backup containing s3 uploads again.
These appear to be the relevant errors. It doesnt mean anything to me.
.............................................................................................................................................#<Thread:0x00007f5426c22fc8 /var/www/discourse/lib/file_store /to_s3_migration.rb:218 run> terminated with exception (report_on_exception is true):
/usr/local/lib/ruby/3.2.0/net/http/response.rb:160:in `read_status_line': wrong status line: "0" (Net::HTTPBadResponse)
from /usr/local/lib/ruby/3.2.0/net/http/response.rb:147:in `read_new'
from /usr/local/lib/ruby/3.2.0/net/http.rb:1862:in `block in transport_request'
from /usr/local/lib/ruby/3.2.0/net/http.rb:1853:in `catch'
from /usr/local/lib/ruby/3.2.0/net/http.rb:1853:in `transport_request'
from /usr/local/lib/ruby/3.2.0/net/http.rb:1826:in `request'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.1.0/lib/patches/net_patches.rb:19:in `block in request_with_mini_profiler'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.1.0/lib/mini_profiler/profiling_methods.rb:46:in `step'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.1.0/lib/patches/net_patches.rb:18:in `request_with_mini_profiler'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/net_http/connection_pool.rb:348:in `request'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/net_http/handler.rb:79:in `block in transmit'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/net_http/handler.rb:133:in `block in session'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/net_http/connection_pool.rb:104:in `session_for'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/net_http/handler.rb:128:in `session'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/net_http/handler.rb:76:in `transmit'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/net_http/handler.rb:50:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/content_length.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:85:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/s3_signer.rb:132:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/s3_signer.rb:63:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/s3_host_id.rb:17:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/xml/error_handler.rb:10:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/transfer_encoding.rb:26:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/helpful_socket_errors.rb:12:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/s3_signer.rb:110:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/redirects.rb:20:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/retry_errors.rb:360:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/md5s.rb:31:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/http_checksum.rb:19:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/endpoint_pattern.rb:30:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:67:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:136:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/bucket_dns.rb:35:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:41:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/expect_100_continue.rb:22:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/bucket_name_restrictions.rb:26:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/arn.rb:62:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/rest/handler.rb:10:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/recursion_detection.rb:18:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/user_agent.rb:13:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/endpoint.rb:47:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_validator.rb:26:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/arn.rb:88:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:16:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
from /var/www/discourse/lib/file_store/to_s3_migration.rb:220:in `block (2 levels) in migrate_to_s3'
O erro parece estar relacionado à movimentação dos uploads do backup para o S3. Esses arquivos já existem de qualquer forma, então isso pode ser parte do problema? Ou talvez seja apenas o meu provedor de S3 continuando a ter problemas, que é por isso que estou tentando me afastar deles.
De qualquer forma, pesquisando encontrei isto:
Parece que talvez isso ainda se aplique.
Extrair o dump do banco de dados do backup e descompactá-lo novamente, apenas para ter o software descompactando-o novamente , é um tanto demorado. Talvez possa ser útil especificar isso usando um comando do Discourse no contêiner ou via app.yml. Talvez uma seção para ‘substituição de configurações do banco de dados’ que o processo de restauração verifica primeiro? Principalmente apenas dando ideias porque eu só finjo que sei o que estou fazendo aqui.
após modificar o dump.sql necessário, a restauração é concluída com sucesso, mas os avatares parecem quebrados e algumas miniaturas não parecem funcionar, mas quando você clica na imagem, ela carrega corretamente.
Acho que talvez um rebake possa resolver o último problema. Não estou muito chateado se tudo o que perder forem avatares.
Então, para recapitular para qualquer outra pessoa que encontrar este problema, aqui está o que consegui fazer funcionar para migrar do S3 e mudar para hardware diferente.
Coloque seu servidor em somente leitura e ative a configuração oculta do site para fazer backup de uploads do S3 (e locais), detalhado aqui
Faça um backup com os uploads do S3 ativados nas configurações do seu site. Você precisará de armazenamento local suficiente para baixá-los todos, caso contrário, a tarefa de backup falhará.
Obtenha a versão mais recente do discourse do github e copie seu app.yml.
Reconstrua com seu app.yml e verifique se você obtém a página de configuração do discourse.
Extraia o dump.sql do backup que você fez e modifique-o de forma semelhante ao que é dito aqui.
Recomprima o banco de dados dump.sql no backup e coloque o backup em /var/discourse/shared/standalone/backups/default com o mesmo nome que tinha quando você fez o backup. (este nome é importante, portanto, não o trunque)
Execute o processo de restauração conforme mostrado aqui
se você está simplesmente tentando migrar do S3 sem mudar de hardware, acredito que o processo seja praticamente o mesmo, mas você pularia os passos 3 e 4.
Gostaria de ressaltar que, se você estiver executando uma tarefa de backup manual e uma agendada tentar ser executada, ambas falharão. Parece que pelo menos o backup manual deveria continuar, embora meu problema provavelmente seja considerado um caso extremo.
, é um tanto demorado. Talvez possa ser útil especificar isso usando um comando do Discourse no contêiner ou via app.yml. Talvez uma seção para ‘substituição de configurações do banco de dados’ que o processo de restauração verifica primeiro? Principalmente apenas dando ideias porque eu só finjo que sei o que estou fazendo aqui.