Restauration multisite des fichiers uploadés vers « default » au lieu du nom réel de la base de données

Dev
1

Sur la dernière version bêta de Discourse, installation Docker, multisite.

Je tente de restaurer une sauvegarde avec la base de données originale REDACTED vers la base de données actuelle db8015. Les pièces jointes se retrouvent dans default, tant sur le système de fichiers que dans la base de données.

Cela se produit aussi bien lorsque la restauration est déclenchée depuis l’interface graphique que lorsqu’elle est effectuée en ligne de commande avec RAILS_DB=db8015 RAILS_ENV=production script/discourse restore.

Pendant le processus de restauration, RailsMultisite::ConnectionManagement.current_db passe de la base de données correcte à default. J’ai pu identifier le problème à [Rake::Task['db:_dump'].invoke dans db.rake](https://github.com/discourse/discourse/blame/master/lib/tasks/db.rake#L59).

Avant cette ligne, RailsMultisite::ConnectionManagement.current_db avait la bonne valeur (db8015), après cette ligne, il devient default.

Il semble que cette correction ait cassé la production d’une manière ou d’une autre @sam ?

Journaux :

[COMMENCÉ]
'DHSupport' a lancé la restauration !
Marquage de la restauration comme en cours...
Vérification de l'existence de /var/www/discourse/tmp/restores/db8015/2019-10-11-104940...
Copie de l'archive vers le répertoire tmp...
Décompression de l'archive, cela peut prendre un certain temps...
Aucun fichier de métadonnées à extraire.
Validation des métadonnées...
  Version actuelle : 20191007140446
  Version restaurée : 20190908234054
Extraction du fichier de dump...
Création des fonctions manquantes dans le schéma discourse_functions
Impossible de restaurer dans un schéma différent, restauration in-place
Activation du mode lecture seule...
Mise en pause de sidekiq...

[suppression d'un grand nombre d'éléments non pertinents]

Vidage du cache des thèmes
Extraction des pièces jointes...
Remappage des pièces jointes...
Remappage de 'uploads/REDACTED' vers 'uploads/default'
Optimisation des icônes du site...
Les publications seront retransformées par un travail en arrière-plan dans sidekiq. Vous verrez des images manquantes jusqu'à ce que cela soit terminé.
Vous pouvez accélérer le processus en exécutant manuellement "rake posts:rebake_uncooked_posts"
Exécution du crochet after_restore...
Nettoyage...
Suppression de la fonction du schéma discourse_functions
Suppression du répertoire tmp '/var/www/discourse/tmp/restores/db8015/2019-10-11-104940'...
Reprendre sidekiq...
Marquage de la restauration comme terminée...
2

Est-ce que c’est toujours un problème @sam ?

3

Pour clarifier, la reproduction est la suivante :

  • Créer un multisite dans un conteneur Docker

  • Sauvegarder l’un des multisites

  • Dans un nouveau conteneur Docker, le restaurer

  • Les fichiers uploadés se trouvent au mauvais emplacement

@kris.kotlarek, peux-tu reproduire ce problème en local et voir si tu peux le corriger ?

Je soupçonne que nous serons confrontés à cela à l’avenir.

6

Seul le conteneur de destination doit être multisite pour reproduire ce problème.

  • Créez un forum dans un conteneur Docker
  • Créez une sauvegarde
  • Dans un nouveau conteneur Docker multisite, restaurez-la
  • Les fichiers uploadés se trouvent au mauvais endroit
7

J’ai passé un certain temps sur ce bug et je voulais vous faire part de mes découvertes. En gros, j’ai confirmé tout ce que vous avez déjà dit : le processus de restauration se déroule comme suit :

migrate_database
reconnect_database
...
extract_uploads

Le problème est qu’après la tâche de migration, reconnect_database ne bascule pas vers la base de données souhaitée, mais commence à travailler sur la base par défaut.

Par conséquent, ce code est incorrect :

def extract_uploads
  ...
  current_db_name = 
  RailsMultisite::ConnectionManagement.current_db # default
  optimized_images_exist = File.exist?(File.join(tmp_uploads_path, 'optimized'))

Une solution rapide consisterait à utiliser ici @current_db, qui contient toujours le nom correct, au lieu de RailsMultisite::ConnectionManagement.current_db, mais cela ne résout pas le vrai problème de pourquoi reconnect_database ne fonctionne pas correctement.

Je dois creuser plus profondément pour trouver la cause du problème.

8

Êtes-vous certain que cela se produit après la tâche de migration ?

Ce code

  migrate_database
  puts "Après la migration, avant la reconnexion #{RailsMultisite::ConnectionManagement.current_db}"
  reconnect_database

produit le résultat suivant

Optimisation des icônes du site... Terminé
Après la migration, avant la reconnexion default
Reconnexion à la base de données...

Mais lorsque vous commentez la ligne

Rake::Task['db:_dump'].invoke

dans lib/tasks/db.rake

Le résultat est le suivant

Optimisation des icônes du site... Terminé
Après la migration, avant la reconnexion db8015
Reconnexion à la base de données...
9

Vous avez raison. J’ai supprimé Rake::Task["db:migrate"].invoke de restorer.rb et j’ai obtenu une base de données correcte tout au long du processus. Vous avez une longueur d’avance sur moi ; mon plan est maintenant d’examiner la tâche de migration pour identifier l’étape qui bloque le processus. Merci d’avoir signalé _dump ; je vais me rendre directement là pour voir ce qui se passe à l’intérieur.

10

J’ai passé un peu de temps à enquêter là-dessus, mais j’ai finalement trouvé une solution :slight_smile:

11

Merci !

Après y avoir réfléchi davantage, qu’est-ce que cela signifie exactement lorsque db:dump est exécuté sur une base de données qui n’est pas la base principale ?

Ne devrait-il pas simplement ignorer la commande db:dump si la base de données n’est pas la base par défaut ?

16

La correction a été intégrée, merci d’avoir signalé ce problème. La commande de vidage a été ajoutée car il y avait un problème avec les migrations multisites. Je pense que cela ne devrait pas avoir d’importance quelle base de données nous utilisons pour exporter la structure, car tous les sites multisites devraient avoir la même structure.