La restauration échoue avec "hotlinked_media_status" existe déjà

Continuant la discussion de La mise à niveau échoue avec une erreur de clé en double (« index post hotlinked media on post id and url md5 ») :

J’essaie maintenant de restaurer un site de production sur un site de staging et j’obtiens :

ERROR:  type "hotlinked_media_status" already exists
EXCEPTION: psql failed: ERROR:  type "hotlinked_media_status" already exists

@david y a-t-il un cas que tu aurais manqué lorsque tu as corrigé cela auparavant (je pense que cela échouait sur les migrations alors, et ceci est une restauration).

1 « J'aime »

Comment restaurez-vous le site ? Via l’interface utilisateur ? CLI discourse ? psql direct ?

Depuis la ligne de commande, restauration de la sauvegarde la plus récente (j’ai découvert cette astuce sed aujourd’hui, mais c’était la même chose si je copiais/collais).

$(discourse restore |sed -n '3p')

Et la sauvegarde est sur S3 restaurée à partir d’une version légèrement plus ancienne :

Discourse 3.4.0.beta1-dev - https://github.com/discourse/discourse version a3d61ba1c43931eb688f9b2b85c207b5bab02b8c

vers

Discourse 3.4.0.beta2-dev - https://github.com/discourse/discourse version f405c021ebd36d5f11499159bd2b54098356a8f9"

Êtes-vous en mesure de reproduire le problème sur une autre installation ?

Il est assez surprenant que ce problème survienne plus de 2 ans plus tard, et sans aucun autre rapport :thinking:

Peut-être pas ? J’ai réussi à restaurer cette même sauvegarde sur ma machine de développement.

Avez-vous une idée de ce que j’aurais pu faire pour causer cela ou de ce que je peux faire pour le résoudre ? J’ai supprimé la base de données et j’ai ensuite pu restaurer. La suppression de la base de données était la solution réelle, mais je ne mérite pas de solution pour un problème que j’ai (semble-t-il) causé.

Ce sujet a été automatiquement fermé 30 jours après la dernière réponse. Les nouvelles réponses ne sont plus autorisées.

Une idée très précieuse que je viens d’avoir est que hotlinked_media_status est simplement la première chose qui se passe dans le fichier de restauration. Si vous le supprimez manuellement dans la base de données existante, la restauration échouera à l’instruction suivante (CREATE TABLE public.admin_notices).

Il ne s’agit donc pas de cette définition de type spécifique. C’est juste le symptôme d’un problème plus vaste, je soupçonne que BackupRestore.move_tables_between_schemas(MAIN_SCHEMA, BACKUP_SCHEMA) ne parvient pas à faire ce qu’il doit faire.

1 « J'aime »