Multisite stellt Uploads auf „default" statt auf den tatsächlichen DB-Namen wieder her

Entwickler
1

Auf der neuesten Beta-Version von Discourse, Docker-Installation, Multisite.

Ich versuche, ein Backup mit der ursprünglichen Datenbank REDACTED auf die aktuelle Datenbank db8015 wiederherzustellen. Uploads landen sowohl im Dateisystem als auch in der Datenbank in default.

Dies tritt sowohl auf, wenn die Wiederherstellung über die GUI ausgelöst wird, als auch wenn sie über die Kommandozeile mit RAILS_DB=db8015 RAILS_ENV=production script/discourse restore durchgeführt wird.

Während des Wiederherstellungsprozesses ändert sich RailsMultisite::ConnectionManagement.current_db von der korrekten Datenbank zu default. Ich konnte dies auf [Rake::Task['db:_dump'].invoke in db.rake](https://github.com/discourse/discourse/blame/master/lib/tasks/db.rake#L59) zurückführen.

Vor dieser Zeile hat RailsMultisite::ConnectionManagement.current_db den korrekten Wert (db8015), danach ist er default.

Es scheint, als hätte diese Korrektur die Produktion irgendwie beschädigt, @sam?

Logs:

[STARTED]
'DHSupport' hat die Wiederherstellung gestartet!
Markiere Wiederherstellung als laufend...
Stelle sicher, dass /var/www/discourse/tmp/restores/db8015/2019-10-11-104940 existiert...
Archiv in tmp-Verzeichnis kopieren...
Archiv entpacken, das kann eine Weile dauern...
Keine Metadatendatei zum Extrahieren.
Metadaten validieren...
  Aktuelle Version: 20191007140446
  Wiederhergestellte Version: 20190908234054
Dump-Datei extrahieren...
Fehlende Funktionen im discourse_functions-Schema erstellen
Kann nicht in ein anderes Schema wiederhergestellt werden, stattdessen wird vor Ort wiederhergestellt
Nur-Lese-Modus aktivieren...
Sidekiq pausieren...

[viele irrelevante Teile gelöscht]

Theme-Cache leeren
Uploads extrahieren...
Uploads neu mappen...
'uploads/REDACTED' wird auf 'uploads/default' neu gemappt
Site-Icons optimieren...
Beiträge werden durch einen Hintergrundjob in Sidekiq neu gebacken. Bis dies abgeschlossen ist, werden fehlende Bilder angezeigt.
Sie können den Prozess beschleunigen, indem Sie manuell "rake posts:rebake_uncooked_posts" ausführen.
Den after_restore_hook ausführen...
Aufräumen...
Funktion aus dem discourse_functions-Schema entfernen
tmp-Verzeichnis '/var/www/discourse/tmp/restores/db8015/2019-10-11-104940' entfernen...
Sidekiq wieder aktivieren...
Wiederherstellung als abgeschlossen markieren...
2

Ist das immer noch ein Problem, @sam?

3

Nur zur Klarstellung: Die Reproduktion erfolgt wie folgt:

  • Erstellen einer Multisite in einem Docker-Container

  • Sichern einer der Multisites

  • Wiederherstellen in einem neuen Docker-Container

  • Uploads befinden sich am falschen Ort

@kris.kotlarek, kannst du dies lokal reproduzieren und prüfen, ob du es beheben kannst?

Ich vermute, dass wir in Zukunft davon betroffen sein werden.

6

Nur der Ziel-Container muss für die Reproduktion dieses Problems multisite-fähig sein.

  • Erstellen Sie ein Forum in einem Docker-Container
  • Erstellen Sie ein Backup
  • Stellen Sie es in einem neuen multisite-fähigen Docker-Container wieder her
  • Uploads befinden sich am falschen Ort
7

Ich habe mich etwas mit diesem Fehler beschäftigt und möchte Sie über meine Erkenntnisse auf dem Laufenden halten. Grundsätzlich habe ich alles bestätigt, was Sie bereits gesagt haben: Der Wiederherstellungsprozess verläuft wie folgt:

migrate_database
reconnect_database
...
extract_uploads

Das Problem ist, dass nach der Migration reconnect_database nicht auf die gewünschte Datenbank wechselt, sondern standardmäßig weiterarbeitet.

Daher ist dieser Code falsch:

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

Eine Workaround-Lösung wäre, hier @current_db zu verwenden, das noch den korrekten Namen enthält, anstatt RailsMultisite::ConnectionManagement.current_db. Dies löst jedoch nicht das eigentliche Problem, warum reconnect_database nicht ordnungsgemäß funktioniert.

Ich muss tiefer graben, um die Ursache des Problems zu finden.

8

Bist du dir sicher, dass dies nach der Migration stattfindet?

Dieser Code

  migrate_database
  puts "Nach der Migration, vor der Wiederherstellung #{RailsMultisite::ConnectionManagement.current_db}"
  reconnect_database

liefert folgende Ausgabe:

Optimierung der Site-Symbole... Fertig
Nach der Migration, vor der Wiederherstellung default
Verbindung zur Datenbank wird wiederhergestellt...

Wenn du jedoch die Zeile

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

in lib/tasks/db.rake auskommentierst,

lautet die Ausgabe:

Optimierung der Site-Symbole... Fertig
Nach der Migration, vor der Wiederherstellung db8015
Verbindung zur Datenbank wird wiederhergestellt...
9

Du hast recht. Ich habe Rake::Task["db:migrate"].invoke aus restorer.rb entfernt und habe den gesamten Prozess über eine korrekte Datenbank erhalten. Du bist mir einen Schritt voraus. Mein Plan ist es nun, in die Migrate-Aufgabe zu gehen und zu prüfen, welcher Schritt den Prozess unterbricht. Danke dafür, dass du auf _dump hingewiesen hast. Ich werde mich direkt dorthin begeben, um zu sehen, was dort im Inneren passiert.

10

Ich habe mir etwas Zeit genommen, das zu untersuchen, und habe schließlich eine Lösung gefunden :slight_smile:

11

Danke!

Nach etwas mehr Überlegung: Was bedeutet es eigentlich, wenn db:dump auf etwas ausgeführt wird, das nicht die primäre Datenbank ist?

Sollte der Befehl db:dump nicht einfach übersprungen werden, wenn die Datenbank nicht die Standarddatenbank ist?

16

Der Fix wurde zusammengeführt. Danke, dass du das Problem gefunden hast. Der Dump-Befehl wurde hinzugefügt, weil es ein Problem mit Multisite-Migrationen gab. Ich denke, es sollte keine Rolle spielen, welche Datenbank wir für den Struktur-Dump verwenden, da alle Multisites die gleiche Struktur haben sollten.