J’essaie de restaurer à partir d’un serveur récent vers un serveur construit aujourd’hui. Cela échoue avec cette erreur. Je ne vois rien de tel dans le code de Discourse ou dans le code du plugin.
Je ne sais pas quoi faire ensuite.
[20/9694]
ERREUR : la fonction discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() n'existe pas
EXCEPTION : psql a échoué : ERREUR : la fonction discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() n'existe pas
/var/www/discourse/lib/backup_restore/database_restorer.rb:92:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:51:in `run'
script/discourse:157:in `restore'
/var/www/discourse/vendor/bundle/ruby/3.
Même erreur ici en essayant de restaurer sur une nouvelle installation alors que j’essayais de déplacer mon discourse vers un autre serveur. Aucune solution trouvée.
J’ai eu de la chance, l’ancien serveur fonctionne toujours. J’ai donc reconstruit l’application du lanceur pour que l’ancien serveur soit exactement à la même version que la nouvelle installation. Ensuite, j’ai effectué une autre sauvegarde en ligne de commande. Lors de la restauration de cette sauvegarde sur la nouvelle installation, tout s’est bien passé. Vous devriez essayer cela. @pfaffman
Oups, j’ai aussi rencontré ce problème. J’essaie de restaurer à partir d’un système de production vers un environnement sandbox/dev. J’ai également vérifié que tous les mêmes plugins sont installés.
Quel autre plugin utilise ceci ? Je vais vérifier la source tout de suite…
Assurez-vous que le dossier /var/discourse/shared était vide, ou déplacé vers un nouvel emplacement au cas où nous aurions besoin de restaurer.
Initialisé une nouvelle instance de Discourse en utilisant ./launcher bootstrap <app>
J’ai réessayé la restauration et elle a toujours échoué avec le même message d’erreur.
Ensuite, lorsque j’ai fait un dump de mon instance Discourse fonctionnelle, j’ai trouvé la commande réelle qui crée la fonction. C’est :
CREATE FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
RAISE EXCEPTION 'Discourse: old_notification_id in chat_mention_notifications is readonly';
END
$$;
ALTER FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() OWNER TO discourse;
Puis j’ai retenté la restauration, et tout s’est bien passé !
Maintenant, j’avais le log où ça a échoué et j’ai pensé que je pourrais y revenir plus tard, mais les logs sont réinitialisés à chaque fonctionnalité de sauvegarde/restauration.
AMÉLIORATION : Ce serait bien d’avoir un historique des sauvegardes/restaurations. Peut-être qu’il en existe un et que je ne sais pas où il se trouve.
AVERTISSEMENT : Je ne suis pas une personne du support de Discourse, donc je n’expliquerai pas comment accéder à l’invite de commande psql pour exécuter les commandes ci-dessus. :
Le problème est qu’une migration avec un ancien horodatage a été validée dans tests-passed plus tard (@nbianca FYI), et cela n’est pas détecté par les métadonnées de version dans la sauvegarde. J’en ai parlé ici.
C’est la solution. Vous devez donc soit obtenir le hash de commit du serveur d’instance et construire votre nouvelle instance avec ce commit, soit mettre à jour l’instance existante vers la dernière version, ce qui exécutera cette migration, puis effectuer une nouvelle sauvegarde.
Dites-vous que la solution (actuelle ?) perpétuelle consiste à ne restaurer que le même commit (ou en fait la migration) qui a effectué la sauvegarde ?
Ou si les deux versions sont au-delà du commit erroné, serons-nous d’accord ?
Oui, mais parfois vous ne pourrez pas mettre à jour l’instance source. Et dans ce cas, vous devrez placer la destination sur le même commit que la source. C’est donc une exception à la situation normale où vous pouvez toujours effectuer une migration implicite vers l’avant lors de la restauration.
Je vais tester cela aujourd’hui, mais mon hypothèse actuelle est que la restauration fonctionne dès que le site de destination est entièrement à jour.
Il semble que le problème soit que la vérification de version au début de la restauration ne détecte pas que la source avait en fait un schéma de base de données plus récent que la destination.
Correct, et cela se produit parce que la migration n’a pas l’horodatage du moment où elle a été validée, mais l’horodatage du moment où elle a été générée. La plupart du temps, cela n’a pas d’importance, mais dans ce cas, il y avait 7 semaines entre ces deux moments.
Oui, c’est un cas limite malheureux. Nous pouvons essayer de l’éviter à l’avenir ou de trouver une solution rétrocompatible pour éviter qu’elle ne se reproduise. Cependant, je ne pense pas que nous puissions faire quoi que ce soit pour la corriger dans ce cas. C’est un navire qui a levé l’ancre. Quoi que nous fassions, cela nécessitera toujours que les propriétaires de sites mettent à jour leur site de destination vers la dernière version.
Correct, c’est un problème avec ce genre de techniques en général, c’est un problème générique pour Ruby on Rails et aussi pour d’autres implémentations AR comme PHP Laravel. Et comme vous l’avez dit, cela n’arrive pas souvent, et une fois que vous réalisez ce qui se passe, il est facile de contourner le problème lors de la restauration.
Dans mon scénario, mon environnement de restauration était plus récent de quelques versions de l’assurance qui avait été sauvegardée. Cela ne devrait-il pas fonctionner alors ?
c’était quelque chose que j’allais examiner ! une seconde. j’aurais aimé que nous conservions un journal des sauvegardes précédentes, ou est-ce que nous en avons un ?
Puisqu’il s’agit du bac à sable vers lequel nous restaurons, je l’ai relancé. Il s’agit d’une restauration de la production vers le bac à sable :
Voici les chiffres du journal de restauration :
[2024-10-21 19:49:59] Version actuelle : 20241018031851
[2024-10-21 19:49:59] Version restaurée : 20241011054348
