Une organisation à but non lucratif pour laquelle je travaille utilise une installation Discourse 2.9.0.beta1, dont la maintenance m’est revenue lorsque l’administrateur d’origine est parti. Lorsque j’ai essayé de mettre à jour les informations d’identification SMTP, j’ai appris que l’installation ne peut ni se reconstruire ni se mettre à niveau en toute sécurité, que ce soit via le web ou la ligne de commande. (Si je n’avais pas eu une sauvegarde à chaud de l’instance faite avant le début du travail, cela aurait été un mauvais moment.) Le problème semble se produire assez profondément dans Ruby, et je peux capturer des journaux s’ils semblent utiles.
J’ai pensé qu’elle était peut-être tout simplement trop ancienne pour être mise à niveau avec succès, j’ai donc essayé un processus de récupération à la place, en créant une nouvelle instance Discourse vierge, puis en chargeant la sauvegarde la plus récente du forum, mais ce processus a également échoué de manière non concluante, avec ce qui me semble être des erreurs de colonnes de base de données avant que le processus de mise à niveau ne devienne non réactif.
Quelle serait la meilleure façon de procéder à partir de là où nous en sommes ? Le forum est actuellement fonctionnel à l’heure actuelle, mais je ne peux ni le mettre à niveau ni, apparemment, utiliser une sauvegarde. Dois-je continuer à essayer la récupération, dois-je redoubler d’efforts pour mettre à niveau et capturer des journaux pour commencer, ou y a-t-il une troisième option que je ne vois pas ?
Vous devez migrer vers une nouvelle machine virtuelle. Il est probable que votre système d’exploitation soit trop ancien pour mettre à niveau Docker vers une version prise en charge.
Il est préférable de migrer vers une nouvelle VM qui sera sur du matériel plus récent, plus rapide et moins cher.
Le versionnement de Docker ne semble pas avoir joué un rôle dans l’effondrement des builds Ruby, mais je suppose que c’est possible. Les tirages Docker qui faisaient partie de la reconstruction ne semblaient présenter aucun état d’échec exceptionnel. Cela semble pouvoir être essayé, cependant. Merci pour votre réponse !
Votre migration a été un peu plus compliquée par le fait que vous aviez des sauvegardes sur S3 configurées dans la base de données plutôt que dans des variables d’environnement comme décrit dans Configurer un fournisseur de stockage d’objets compatible S3 pour les téléchargements (bien que ce soit pour les téléchargements, vous n’auriez donc pas à utiliser le paramètre use_s3, juste le compartiment et l’emplacement de sauvegarde. EDIT : Et ensuite, la restauration a échoué car votre EC2 n’a pas les droits d’écriture sur le compartiment.
Avoir un équilibreur de charge devant votre site change également les choses par rapport à la situation de la plupart des gens.
Et comme vos identifiants sont pour l’EC2 plutôt que de les avoir dans la base de données ou le fichier YML, la restauration ne peut pas aboutir.