Dopo aver riscontrato numerosi disservizi e problemi con il nostro provider S3 (vultr), ho pensato fosse meglio affrontare i caricamenti del sito in modo diverso. Il loro VPS è stato affidabile, ma lo storage a oggetti fallisce molto più spesso. Sto anche considerando la migrazione su hardware nuovo di mia proprietà per risparmiare $$$, ma il primo ostacolo sembra essere la mancanza di un modo per migrare da S3 a locale. Vedo che il task rake che doveva servire a questo scopo è ora scomparso e l’operazione di backup/ripristino consigliata sembra avere problemi da parte mia.
Ho un server attualmente operativo su forum.tld e il nuovo hardware di destinazione è in esecuzione su forum2.tld. Ho abilitato le impostazioni nascoste del sito per il backup dei caricamenti ed eseguito il task di backup.
Quando eseguo il task di backup con S3 abilitato, sembra effettivamente catturare tutti i caricamenti pertinenti, ma il ripristino di questo backup fallisce (e sembra utilizzare comunque S3).
Quando disabilito S3 prima di eseguire il backup e il ripristino, questo riesce a ripristinare, ma ovviamente i caricamenti S3 sono interrotti. Posso unire i caricamenti dall’altro backup ma semplicemente facendo un rebake non sembra aggiornare correttamente i post.
Sono abbastanza fortunato da avere il secondo server per provare tutte le cose stupide, quindi se qualcuno ha un’idea stupida sono più che disposto a prenderla in considerazione.
Semplicemente non vedo un buon percorso per abbandonare S3 una volta implementato. Ho post più vecchi di quando siamo migrati da AWS e poi di nuovo a vultr che si sono interrotti e ho rinunciato a cercare di capirci qualcosa. Sembra che tutti i caricamenti siano sottoposti a hash sha1 e rinominati, quindi aggiunti a una sorta di mappatura separata dal database. Questo processo sembra essere un affare solo a senso unico. Forse uno sviluppatore può intervenire con una traccia per generare questa mappatura?
C’è un modo per farlo senza un’operazione di backup/ripristino?
Qual è il percorso previsto/inteso per qualcuno che migra da S3 attualmente?
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'
L’errore sembra essere correlato allo spostamento dei caricamenti dal backup a S3. Questi file esistono già, quindi potrebbe essere parte del problema? o forse è solo il mio provider S3 che continua ad avere problemi, motivo per cui sto cercando di allontanarmene.
In ogni caso, scavando ho trovato questo:
Sembra che questo si applichi ancora.
Estrarre il dump del database dal backup e decomprimerlo, solo per poi far sì che il software lo decomprima di nuovo , richiede un po’ di tempo. Forse potrebbe essere utile specificarlo sia utilizzando un comando discourse nel container sia tramite app.yml. Forse una sezione per ‘sovrascrittura impostazioni db’ che il processo di ripristino controlla per prima? Principalmente sto solo lanciando idee perché fingo solo di sembrare che sappia cosa sto facendo qui.
dopo aver modificato il dump.sql necessario, il ripristino viene completato con successo ma gli avatar sembrano danneggiati e alcune miniature non sembrano funzionare, ma quando si fa clic sull’immagine, questa si carica correttamente.
Penso che forse un rebake potrebbe risolvere quest’ultimo problema. Non sono molto turbato se tutto ciò che perdo sono gli avatar.
Quindi, per riassumere per chiunque altro si imbatta in questo problema, ecco cosa sono riuscito a far funzionare per migrare da S3 e passare a hardware diverso.
Metti il tuo server in sola lettura e abilita l’impostazione del sito nascosta per il backup dei caricamenti S3 (e locali), dettagliato qui.
Esegui un backup con i caricamenti S3 abilitati nelle impostazioni del tuo sito. Avrai bisogno di spazio di archiviazione locale sufficiente per scaricarli tutti, altrimenti l’attività di backup fallirà.
Scarica l’ultima versione di discourse da github e copia il tuo app.yml.
Ricompila con il tuo app.yml e verifica di ottenere la pagina di configurazione di discourse.
Estrai il dump.sql dal backup che hai effettuato e modificalo in modo simile a quanto detto qui.
Ricomprimi il database dump.sql nel backup e metti il backup in /var/discourse/shared/standalone/backups/default con lo stesso nome che aveva quando hai effettuato il backup. (questo nome è importante, quindi non troncarlo)
Esegui il processo di ripristino come mostrato qui.
Se stai semplicemente cercando di migrare da S3 senza cambiare hardware, credo che il processo sia in gran parte lo stesso, ma salteresti i passaggi 3 e 4.
Vorrei far notare che se si sta eseguendo un’attività di backup manuale e una pianificata tenta di avviarsi, entrambe falliranno. Sembra che dovrebbe almeno continuare il backup manuale, anche se il mio problema è probabilmente considerato un caso limite.
, richiede un po’ di tempo. Forse potrebbe essere utile specificarlo sia utilizzando un comando discourse nel container sia tramite app.yml. Forse una sezione per ‘sovrascrittura impostazioni db’ che il processo di ripristino controlla per prima? Principalmente sto solo lanciando idee perché fingo solo di sembrare che sappia cosa sto facendo qui.