Wenn ich Sie richtig verstehe, hatten Sie keine Probleme, die vorherigen Schritte auszuführen, die import.yml neben app.yml zu erstellen/bearbeiten, den import-Container neu zu erstellen, und jetzt können Sie ihn nicht einmal mehr betreten. Stimmt das? Das ist sicher seltsam!
Was gibt dieser Befehl zurück? ls -l /var/discourse/containers
Es ist immer noch dasselbe: app.yml und import.yml (plus eine „bak“-Datei von app.yml).
Es könnte „Probleme“ geben, da ich versucht habe, dies auf Lightsail 1GB zu installieren (was anfangs 940 und nach dem Aktualisieren von Ubuntu „921MB“ beträgt). Ich habe die offizielle Installation verwendet und was installiert wurde, war etwas wie 3.3.* Beta-irgendwas (während Wiki 3.2 als die neueste stabile Version anzeigt). Die Installation dauert 1h15min-1h20min mit 4GB Swap. Das „launcher rebuild import“ etwa 2h.
Könnte etwas aufgrund des geringen Speichers falsch beendet worden sein?
Übrigens, sind Backup-Dateien vom 2GB-Setup auf dem 1GB-Setup lesbar?
War es erfolgreich? Nach einem Rebuild sollte der Container gestartet werden.
Sie können den Container nicht betreten, wenn er nicht gestartet ist (./launcher start import)
Das wäre wahrscheinlich der Fall. Es gibt mehrere Themen, die sich auf geringen Speicher/Swap und fehlgeschlagene Rebuilds beziehen – normalerweise bleibt nichts anderes übrig, als den RAM/Swap zu erhöhen.
Ich bin kein Experte, aber hoffentlich kann Ihnen jemand bessere Einblicke geben.
Anscheinend ist RAM ein Problem. Für die Lightsail 2GB/2GB war die Neuinstallation etwa 3,5-4x schneller und der Wiederaufbau des Importcontainers war etwa (oder sogar über) 10x schneller.
Trotzdem befürchte ich, dass das Importskript für phpBB 3.3.3 möglicherweise nicht funktioniert. Jedenfalls habe ich es zweimal mit demselben Ergebnis versucht: Nur ein Wort aus dem Namen einer Kategorie (von ca. 10 Kategorien) wurde als eine leere “Kategorie” importiert. Der MySQL-Textdump ist ziemlich klein, 2,66 MB. Alle Tabellenpräfixe sind wie erforderlich. Keine Bilder, keine Smilies usw.
Alles in allem keine Foren, keine Forenkategorien oder Beiträge, aber alle (ein paar hundert) Benutzer wurden zusammen mit ihren Statistiken korrekt importiert.
Es scheint, dass phpBB 3.3.3 das Update war, das etwas an der verwendeten MySQL-Version geändert hat, aber dies ist hier eine Dump-Datei, daher sollte es am Ende keine Rolle spielen.
Irgendwelche Ideen, was sonst noch überprüft werden kann?
Sie meinen 4 GB, um diese 2,6 MB große Textdatei zu öffnen/lesen/zu parsen? Sind Sie der Discourse-Entwickler? Eine binäre ausführbare Datei, um diesen Dump zu lesen (alle von Discourse verwendeten Daten zu extrahieren) und in etwas anderes zu speichern, sollte meiner Meinung nach etwa 200 KB mit einem, sagen wir, 100 KB Puffer sein (ohne sich um die Einbeziehung der gesamten MariaDB für diese einfache Aktion zu kümmern).
Ich denke, es geht nicht um RAM. Der Vorgang war schnell und zeigte den Importfortschritt für die importierten Tabellen an. Er wurde nicht “abgebrochen”. Die Benutzertabelle befindet sich am Ende des Dumps, nach den Themen usw.
Ich wollte dies erneut tun und experimentieren, indem ich diese Benutzertabelle nach oben kopiere/einfüge und die gleichen Schritte wie oben im Handbuch/auf der Seite durchführe (auch mit einem von phpMyAdmin erstellten Dump anstelle von phpBB), aber jetzt weigert sich Discourse, den Vorgang zu starten und versucht, eine Remoteverbindung herzustellen, obwohl keine Verbindungsdaten hinzugefügt wurden.
Ich habe den Import-Container neu erstellt, aber vielleicht muss zuerst etwas gelöscht werden?
Ich verdiene meinen Lebensunterhalt mit der Unterstützung von Discourse und habe mehr Migrationen durchgeführt, als ich zählen kann, aber ich denke, hundert oder mehr. 2 GB werden wahrscheinlich funktionieren, besonders wenn Sie nur ein paar tausend Themen und Benutzer haben, aber da Sie es für eine kurze Zeit benötigen, ist mehr RAM nicht teuer und kann nicht schaden. Ich stimme zu, dass dies wahrscheinlich nicht das Problem ist.
Als das Skript lief, hat es die Kategorien, Benutzer, Themen und Beiträge durchgezählt?
Das Skript überspringt importierte Daten und erstellt benutzerdefinierte Feld-Daten, um diese in Zukunft zu überspringen. Um es erneut auszuführen, müssen Sie die Discourse-Datenbank löschen. Da Sie sagen, dass nichts importiert wurde, ist nicht klar, ob dies notwendig ist. Es scheint, dass entweder die Daten importiert wurden und Sie sie aus irgendeinem Grund nicht finden können, oder dass der Import fehlgeschlagen ist, weil die Daten nicht gefunden wurden, und Sie das Skript irgendwie ändern müssen; in keinem dieser Fälle sollten Sie die Datenbank löschen müssen.
Nicht ganz:
„alle (ein paar hundert) Benutzer wurden zusammen mit ihren Statistiken korrekt importiert“
Ich habe versucht, den Container erneut zu erstellen. Die gleichen Einstellungen. Ich habe nichts geändert und nach dem Schritt:
import_phpbb3.sh # innerhalb des Docker-Containers
zeigt das Skript jetzt an:
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/mysql2-0.5.6/lib/mysql2/client.rb:97:in `connect’: Unbekannte Datenbank ‘phpbb’ (Mysql2::Error)
Vielleicht gibt es noch einige zuvor verwendete temporäre Dateien zu löschen?
Ich habe schließlich den Dump von phpMyAdmin verwendet. Gibt es ein Beispiel (oder detailliertere Spezifikationen), wie man die Mapping-Abschnitte in der (Import-)settings.yml erstellt?
Meine php_forums-Tabelle sieht wie folgt aus:
Es scheint, dass, welche IDs ich auch verwende und egal ob ich auch den Abschnitt “new_categories: ” angebe, die vom Import-Container generierte Meldung in Ordnung ist:
neue Kategorien erstellen
11 / 11 (100,0%) [2803 Elemente/min] n]
Kategorien erstellen
11 / 11 (100,0%) [2704 Elemente/min]
aber was erstellt wird, sind zwei Hauptkategorien (die in phpBB mit parent_id 0 “Foren” waren) und eine leere Unterkategorie in jeder von ihnen. Das Verfahren importiert zwar alle Beiträge, aber sie sind alle “verwaist”.
Nun, tatsächlich habe ich einen Schritt zur Behebung meines eigenen Fehlers gemacht: Ich habe Kommentare in der Datei settings.yml im C/C+±Stil am Zeilenende platziert. Dies verhinderte offenbar, dass die Unterforen „verarbeitet“ wurden (obwohl keine Fehler angezeigt wurden).
Ich habe die Kategorien und Unterkategorien als „neu“ hinzugefügt und die älteren IDs zugeordnet.
Immer noch gibt es alle Beiträge, die keiner Kategorie zugeordnet sind. Werden solche Themen in einer Postgres-Tabelle gespeichert? Wie können sie gelöscht werden?
Ich habe einige Korrekturen an der phpbb_mysql.sql vorgenommen, zumindest um das Skript alle ursprünglichen Kategorien erstellen zu lassen, aber es reicht nicht aus.
Beim Verarbeiten von Themen/Posts gibt es nur eine lange Liste vom Typ:
und natürlich werden keine Beiträge importiert.
Ich frage mich, ob jemand bestätigen kann, dass die Standard-Skripte nicht mit phpBB 3.3.3 Tabellen funktionieren?
Schließlich konnte ich die phpBB3.3.3-Dumpdatei verwenden, ohne die Kategorien als neu zu definieren und ohne die gesamte Zuordnung in der settings.yml-Datei.
Mit der ursprünglichen phpBB_mysql.sql-Dumpdatei bricht das Migrationsskript beim Schritt, in dem die Kategorien geladen werden, ab und zeigt eine Fehlermeldung bezüglich eines “leeren Kategoriekörpers” an.
Dies tritt auf, wenn das Feld “forum_desc” in der Tabelle “phpbb_forums” für die Hauptkategorien (die keine übergeordneten Kategorien haben) leer ist.
Nach dem Import nur der ersten Kategorie wird der Rest anscheinend durcheinander gebracht.
Die Verwendung einer frischen Installation und die Eingabe von Text in die oben genannten Tabellenfelder scheint dieses Problem zu lösen.
