Après plusieurs pannes et problèmes avec notre fournisseur S3 (vultr), j’ai pensé qu’il serait préférable d’aborder les téléchargements de sites différemment. Leur VPS a été fiable, mais le stockage objet échoue beaucoup plus souvent. J’envisage également de migrer vers mon propre nouveau matériel pour économiser de l’argent, mais le premier obstacle semble être l’absence de moyen de migrer de S3 vers le local. Je vois que la tâche rake qui était censée servir à cet effet a disparu, et l’opération de sauvegarde/restauration recommandée semble avoir des problèmes de mon côté.
J’ai un serveur actuellement opérationnel sur forum.tld et le nouveau matériel cible fonctionne sur forum2.tld. J’ai activé les paramètres cachés du site pour sauvegarder les téléchargements et j’ai exécuté la tâche de sauvegarde.
Lorsque j’exécute la tâche de sauvegarde avec S3 activé, il semble effectivement que toutes les téléchargements pertinents soient capturés, mais la restauration de cette sauvegarde échoue (et semble utiliser S3 de toute façon).
Lorsque je désactive S3 avant d’exécuter la sauvegarde et la restauration, cela réussit la restauration, mais évidemment les téléchargements S3 sont cassés. Je peux fusionner les téléchargements de l’autre sauvegarde, mais le simple fait de faire un rebake ne semble pas mettre à jour correctement les publications.
J’ai la chance d’avoir le deuxième serveur pour essayer toutes les choses stupides, donc si quelqu’un a une idée stupide, je suis plus que disposé à l’envisager.
Je ne vois tout simplement pas de bonne façon de se débarrasser de S3 une fois qu’on l’a implémenté. J’ai d’anciens messages datant de notre migration vers AWS et retour vers vultr qui ont été cassés et j’ai abandonné l’idée de comprendre. Il semble que tous les téléchargements soient hachés en sha1 et renommés, puis ajoutés à une sorte de mappage séparé de la base de données. Ce processus semble être une affaire à sens unique. Peut-être qu’un développeur pourrait intervenir avec une piste pour générer ce mappage ?
Existe-t-il un moyen de le faire sans opération de sauvegarde/restauration ?
Quelle est la voie attendue/prévue pour quelqu’un qui souhaite migrer depuis S3 actuellement ?
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’erreur semble être liée au déplacement des téléchargements de la sauvegarde vers S3. Ces fichiers existent déjà de toute façon, donc cela pourrait faire partie du problème ? ou peut-être que c’est juste mon fournisseur S3 qui continue d’avoir des problèmes, c’est pourquoi j’essaie de m’en éloigner.
Quoi qu’il en soit, en cherchant un peu, j’ai trouvé ceci :
Il semble que cela s’applique toujours.
Extraire la sauvegarde de la base de données de la sauvegarde et la recompresser, pour ensuite avoir le logiciel qui la décompresse à nouveau :premierproblèmedumonde:, prend beaucoup de temps. Peut-être serait-il utile de spécifier cela soit à l’aide d’une commande discourse dans le conteneur, soit via app.yml. Peut-être une section pour ‘db settings override’ que le processus de restauration examine en premier ? Je lance surtout des idées parce que je fais seulement semblant de savoir ce que je fais ici.
après avoir modifié le dump.sql requis, la restauration se termine avec succès mais les avatars semblent cassés et certaines miniatures ne semblent pas fonctionner, mais lorsque vous cliquez sur l’image, elle se charge correctement.
Je pense qu’un nouveau “rebake” pourrait résoudre ce dernier problème. Je ne suis pas très contrarié si je ne perds que les avatars.
Pour résumer pour quiconque rencontre ce problème, voici ce que j’ai réussi à faire pour migrer depuis S3 et passer à du matériel différent.
Mettez votre serveur en lecture seule, et activez le paramètre de site caché pour sauvegarder les uploads S3 (et locaux), détaillé ici
Effectuez une sauvegarde avec les uploads S3 activés dans vos paramètres de site. Vous aurez besoin de suffisamment d’espace de stockage local pour les télécharger tous, sinon la tâche de sauvegarde échouera.
Récupérez la dernière version de discourse depuis github, et copiez votre app.yml.
Recompilez avec votre app.yml et vérifiez que vous obtenez la page de configuration de discourse.
Extrayez le dump.sql de la sauvegarde que vous avez effectuée, et modifiez-le de manière similaire à ce qui est dit ici.
Recompressez la base de données dump.sql dans la sauvegarde et placez la sauvegarde dans /var/discourse/shared/standalone/backups/default avec le même nom qu’elle avait lorsque vous avez effectué la sauvegarde. (ce nom est important, ne le tronquez pas)
Lancez le processus de restauration comme indiqué ici
Si vous essayez simplement de migrer depuis S3 sans changer de matériel, je pense que le processus est en grande partie le même, mais vous sauteriez les étapes 3 et 4.
Je tiens à signaler que si vous exécutez une tâche de sauvegarde manuelle et qu’une tâche planifiée tente de s’exécuter, les deux échoueront. Il semble qu’au moins la sauvegarde manuelle devrait continuer, bien que mon problème soit probablement considéré comme un cas extrême.