Después de tener múltiples interrupciones y problemas con nuestro proveedor de S3 (vultr), pensé que sería mejor abordar las cargas del sitio de manera diferente. Su VPS ha sido confiable, pero el almacenamiento de objetos falla con mucha más frecuencia. También estoy considerando migrar a mi propio hardware nuevo para ahorrar dinero, pero el primer obstáculo parece ser la falta de una forma de migrar de S3 a local. Veo que la tarea de rake que estaba destinada a cumplir este propósito ya no existe, y la operación de copia de seguridad/restauración recomendada parece tener problemas de mi lado.
Actualmente tengo un servidor funcionando en forum.tld y el nuevo hardware de destino se está ejecutando en forum2.tld. Habilité la configuración oculta del sitio para hacer una copia de seguridad de las cargas y ejecuté la tarea de copia de seguridad.
Cuando ejecuto la tarea de copia de seguridad con S3 habilitado, parece que capturo todas las cargas relevantes, pero la restauración de esta copia de seguridad falla (y parece usar S3 de todos modos).
Cuando deshabilito S3 antes de ejecutar la copia de seguridad y la restauración, esta se completa con éxito, pero obviamente las cargas de S3 están rotas. Puedo fusionar las cargas de la otra copia de seguridad, pero simplemente hacer un rebake no parece actualizar correctamente las publicaciones.
Tengo la suerte de tener el segundo servidor para probar todas las cosas tontas, así que si alguien tiene una idea tonta, estoy más que dispuesto a considerarla.
Simplemente no veo un buen camino para deshacerme de S3 una vez que lo has implementado. Tengo publicaciones antiguas de cuando migramos a AWS y de vuelta a vultr que se rompieron y me di por vencido al intentar darles sentido. Parece que todas las cargas se han hashead con sha1 y se han renombrado, y luego se han agregado a algún mapeo separado de la base de datos. Este proceso parece ser una operación unidireccional. ¿Quizás un desarrollador pueda intervenir con una pista para generar este mapeo?
¿Hay alguna forma de hacer esto sin una operación de copia de seguridad/restauración?
¿Cuál es el camino esperado/previsto para que alguien migre desde s3 actualmente?
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'
El error parece estar relacionado con la migración de las cargas de archivos de la copia de seguridad a S3. Estos archivos ya existen de todos modos, ¿así que eso podría ser parte del problema? o quizás sea solo mi proveedor de S3 que sigue teniendo problemas, por eso estoy intentando alejarme de él.
En cualquier caso, investigando encontré esto:
Parece que tal vez esto todavía se aplica.
Extraer el volcado de la base de datos de la copia de seguridad y volver a comprimirlo, solo para que el software lo descomprima nuevamente :problema_de_primer_mundo:, consume bastante tiempo. Quizás podría ser útil especificar esto, ya sea usando un comando de Discourse en el contenedor o a través de app.yml. ¿Quizás una sección para ‘sobrescritura de configuración de la base de datos’ que el proceso de restauración examine primero? Principalmente solo estoy lanzando ideas porque solo pretendo parecer que sé lo que estoy haciendo aquí.
después de modificar el dump.sql necesario, la restauración se completa con éxito, pero los avatares parecen rotos y algunas miniaturas no parecen funcionar, pero cuando haces clic en la imagen, se carga correctamente.
Creo que quizás un rebake podría solucionar este último problema. No me molesta mucho si lo único que pierdo son los avatares.
Então, para recapitular para qualquer outra pessoa que encontre 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 habilite 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 habilitados nas configurações do seu site. Você precisará de armazenamento local suficiente para baixá-los todos, caso contrário, a tarefa de backup falhará.
Baixe 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 ele tinha quando você fez o backup. (este nome é importante, então 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 as etapas 3 e 4.
Me gustaría señalar que si está ejecutando una tarea de copia de seguridad manual y una programada intenta ejecutarse, ambas fallarán. Parece que al menos debería continuar la copia de seguridad manual, aunque mi problema probablemente se considere un caso extremo.