Vielen Dank für die wertvollen Informationen!

Ich habe noch eine Frage zur SQL-Abfrage, die vBulletin-Benutzer auswählt.

Als ich mein altes phpBB-Forum vor 3 Jahren nach Discourse importiert habe, gab es etwa 20.000 Benutzer. Offensichtlich waren die meisten dieser Benutzer ungenutzte Konten. In diesen 3 Jahren hat Discourse eine eigene Bereinigung inaktiver Benutzer durchgeführt, und wir haben jetzt eine realistischere Zahl von 3.000 Mitgliedern.

Als ich meine 180.000 Benutzer aus vBulletin importiert und Discourse aufgefordert habe, aggressiv seine Bereinigungsaufgabe durchzuführen, blieben mir 27.000 Benutzer übrig, was vernünftig erscheint.

Auf meinem vBulletin:

1. Alle Nachrichten, die Benutzer auf den Profilen anderer Benutzer verfasst haben, werden nach Discourse in nicht kategorisierte, titellose Themen importiert, die nichts als unnötigen Lärm hinzufügen, und
2. Die überwiegende Mehrheit der Benutzer, die nur auf den Profilen anderer Benutzer gepostet haben, scheint aus Spammern zu bestehen,
   möchte ich die Bereinigung während des Imports und nicht danach durchführen.

Ich verstehe nicht die gesamte vBulletin-Datenbank, die mit ihren „Nodes

Das hängt davon ab, wo sich Ihre Datenbank befunden hat. Wenn sie von phpBB zu vBulletin migriert wurde oder viele vBulletin-Updates durchlaufen hat, könnte diese Annahme falsch sein.

Das Beste, was Sie tun können, ist, Ihre Annahme durch weitere Abfragen zu überprüfen, zum Beispiel indem Sie alle Beiträge auflisten, die von Benutzern ohne lastpost erstellt wurden.

Außerdem könnten Sie bei Vorhandensein von Plugins wie „Likes“ oder „Abstimmungen“ Benutzer entfernen, die Sie nicht entfernen sollten.

Meine Strategie ist es, beim Entfernen oder Auslassen von Inhalten sehr vorsichtig vorzugehen. Speicherplatz ist kostengünstig.

Vielen Dank, ich werde mich daran halten; ich ziehe es vor, auf Nummer sicher zu gehen.
Ich werde Discourse mit der Zeit seine eigene Bereinigung vornehmen lassen.

Ich füge seit Tagen benutzerdefinierte Regex-Regeln zur Bereinigung von Beiträgen in dein Migrations-Skript ein, da das Forum sehr alt ist und von phpBB vor vBulletin migriert wurde, sodass viele Dinge berücksichtigt werden mussten. Ich denke und hoffe jedoch, dass ich kurz vor dem Abschluss stehe.

Ich kenne vBulletin nicht wirklich, aber das Forum, an dem ich arbeite, nutzte vBulletin 5.6, und einige externe Bilder, die ich dort gepostet habe, verwendeten in der vBulletin-Datenbank folgende Syntax:
[IMG2=JSON]{"data-align":"none","data-size":"full","src":"https:\/\/forum.monocycle.info\/uploads\/default\/original\/2X\/3\/396192845ba93e7df2a6109a2608072efa21ee32.jpeg"}[/IMG2]
Ich bin mir nicht sicher, ob dies etwas war, das in deinem Skript „vergessen“ wurde, oder ob der Forum-Administrator ein Plugin verwendete, das diese IMG2-Tags generierte.

Jedenfalls habe ich diese mit folgendem Code behoben:

    raw = raw.gsub(/\[img2=json\].+?(http.+?).}\[\/img2\]/i) {"\n#{$1}\n"}

Ich habe jedoch eine Frage: Wird Discourse importierte Beiträge im Laufe der Zeit automatisch neu berechnen? Wenn ja, beginnt es dann mit den neuesten Beiträgen?

Hallo nochmal,
mein Forum hat etwa 1000 Tags, die wir aber wahrscheinlich auf Discourse nicht verwenden werden. Außerdem sind diese Tags vermutlich ein echtes Durcheinander. Kann ich diese Zeile im Importer einfach auskommentieren:

    import_tags

Oder könnte das Nebenwirkungen haben?

Sie können es sicher auskommentieren.

Ist es sicher, nicht auf das Beenden der Sidekiq-Jobs nach einem Import zu warten?

Ich habe meine Benutzer importiert, und dies ist der aktuelle Zustand von Sidekiq.

image1182×324 27.3 KB

Was passiert mit diesen Aufgaben, wenn ich ein Backup erstelle und es auf einem Produktionsforum wiederherstelle?

Nein, obwohl ein vollständiger Neubau die meisten dieser Aufgaben neu erstellt, empfehle ich dir dringend, zu warten.

Sie werden weiter ausgeführt… auf der Import-Instanz.
Sie werden nicht in das Backup aufgenommen oder auf das Produktionsforum übertragen.

Danke!

Aufgrund einiger Fehlermeldungen während der Wiederherstellung von Backups (die weder den Abschluss der Wiederherstellung noch die Funktionsfähigkeit des Forums verhindern), habe ich mich gefragt, ob das daran liegen könnte, dass ich nicht auf den Abschluss der Sidekiq-Aufgaben gewartet habe.

Ich habe einen neuen Import aus vBulletin gestartet: Ich habe nur Gruppen und 30.000 Benutzer auf meinem Discourse-Entwicklungssystem importiert, einige Minuten gewartet, dann ein Backup erstellt und dieses auf einer Docker-basierten Installation wiederhergestellt. Die Wiederherstellung funktionierte, aber die Logs zeigen diese Fehler:

ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "users" does not exist LINE 1: SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 ^ ) lib/a
10:03 pm
7
ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "user_auth_tokens" does not exist LINE 1: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((...

Diese sind inkonsistent, und die Relation-Fehler variieren von einem Backup zum nächsten. Ich kann nicht herausfinden, woher diese kommen.

TL;DR: Ich glaube nicht, dass diese Fehler in irgendeiner Weise mit dem Import zusammenhängen.

Ich habe das schon einmal gesehen. Ich denke, es handelt sich um einen Race Condition, der auftritt, weil auf die Datenbank zugegriffen wird, während die Wiederherstellung des Backups läuft.

Das kann durch normalen Verkehr auf deinem Server oder einen Sidekiq-Prozess verursacht werden, der nicht pausiert wurde. In beiden Fällen ist das harmlos. Wenn ich du wäre, würde ich alle PG-Fehler, die vor dem vollständigen Abschluss der Wiederherstellung auftreten, einfach ignorieren.

Das ist beruhigend!

Die Sache ist die: Nicht nur die Nachrichten selbst sind für mich etwas beängstigend, sondern auch, weil:

1. sie bei jedem (oder fast jedem? ) Backup auftreten, das ich seit Beginn meines Imports erstellt habe – egal, ob ich das Backup in einem lokalen Entwicklungsforum oder in einer Docker-Online-Installation wiederherstelle.
2. sie verhindern, dass das Wiederherstellungsprotokoll (in der Discourse-Backup-Oberfläche) während der Wiederherstellung weiter in der Discourse-Oberfläche geschrieben wird: Es bleibt bei „Archiv entpacken

Zuerst einmal vielen Dank für deinen Beitrag. Ich habe gerade versucht, vBulletin 3.7.x zu importieren. Ich habe alle Schritte befolgt, aber als ich das Import-Skript ausgeführt habe, heißt es, es könne keine Verbindung herstellen, obwohl ich eine Verbindung herstellen kann. Hast du eine Idee?

root@uat-app:/var/www/discourse# export DB_NAME="vb4"
root@uat-app:/var/www/discourse# export DB_USER="root"
root@uat-app:/var/www/discourse# export DB_PW="1234"
root@uat-app:/var/www/discourse# export TABLE_PREFIX="vbulletin"
root@uat-app:/var/www/discourse# export ATTACHMENT_DIR='/shared/vbulletin'
root@uat-app:/var/www/discourse# export TIMEZONE="America/Vancouver"
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost will vb4
Lade bestehende Gruppen...
Lade bestehende Benutzer...
Lade bestehende Kategorien...
Lade bestehende Beiträge...
Lade bestehende Themen...
==================================================
Zugriff verweigert für Benutzer 'root'@'localhost'
Kann keine Verbindung zur Datenbank herstellen.

Hostname: localhost
Benutzername: root
Passwort: 1234
Datenbank: vb4

Bearbeite das Skript oder setze diese Umgebungsvariablen:

export DB_HOST="localhost"
export DB_NAME="vbulletin"
export DB_PW=""
export DB_USER="root"
export TABLE_PREFIX="vb_"
export ATTACHMENT_DIR '/path/to/your/attachment/folder'

Beenden.

Unten kannst du sehen, dass ich mich mit denselben Anmeldedaten in die Datenbank einloggen konnte und den Datenbanknamen sowie die Tabellenvorsilbe validiert habe.

root@uat-app:/var/www/discourse# mysql -uroot -p1234 -hlocalhost
Willkommen im MariaDB-Monitor. Befehle enden mit ; oder \g.
Deine MariaDB-Verbindungs-ID ist 70
Server-Version: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab und andere.

Tippe 'help;' oder '\h' für Hilfe. Tippe '\c', um den aktuellen Eingabebefehl zu löschen.

MariaDB [(none)]> use vb4;
Lese Tabelleninformationen für die Vervollständigung von Tabellen- und Spaltennamen
Du kannst diese Funktion deaktivieren, um einen schnelleren Start mit -A zu erreichen

Datenbank gewechselt
MariaDB [vb4]> select * from information_schema.tables where table_schema = 'vb4' and table_name = 'vbulletinpost'
    -> ;
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME    | TABLE_TYPE | ENGINE | VERSION | ROW_FORMAT | TABLE_ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME         | UPDATE_TIME         | CHECK_TIME          | TABLE_COLLATION   | CHECKSUM | CREATE_OPTIONS | TABLE_COMMENT | MAX_INDEX_LENGTH   | TEMPORARY |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| def           | vb4          | vbulletinpost | BASE TABLE | MyISAM |      10 | Dynamic    |    1037509 |            356 |   370191960 | 281474976710655 |     53087232 |         0 |        1046506 | 2020-11-14 14:27:01 | 2020-11-14 14:27:28 | 2020-11-14 14:27:32 | latin1_swedish_ci |     NULL |                |               | 288230376151710720 | N         |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
1 Zeile in der Ausgabe (0,001 Sek)

MariaDB [vb4]>

Außerdem habe ich die Avatare über /admincp/avatar.php?do=storage exportiert und in drei verschiedene Ordner wie folgt gespeichert:

/shared/vbulletin/signaturepics/
/shared/vbulletin/customprofilepics/
/shared/vbulletin/customavatars/

Soll ich dann den übergeordneten Ordner so angeben? Oder muss ich den Inhalt der drei Ordner nehmen und in einen einzigen Ordner zusammenführen?

export ATTACHMENT_DIR='/shared/vbulletin'

Meine einzige Vermutung ist, dass dein Passwort vielleicht Sonderzeichen enthält?

Tatsächlich sind es nur alphanumerische Zeichen. Wie auch immer, ich habe es gerade noch einmal versucht und bestätigt, dass es nicht funktioniert, bis ich das Passwort explizit festlege. Mir ist auch aufgefallen, dass die Anweisungen aktualisiert werden müssen, also poste ich hier, was bei mir funktioniert.

Anweisungen müssen aktualisiert werden. Hier ist, was für mich ab November 2020 funktioniert. Beachten Sie, dass es tatsächlich besser ist, diesen Import über screen auszuführen, da der Import mehrere Stunden dauern kann. Die Verwendung von nohup ist wahrscheinlich nicht hilfreich, da das Import-Skript ständig die Anzahl der importierten Elemente aktualisiert, wodurch die stdout-Datei wahrscheinlich sehr groß wird.

Datenbank für vBulletin-Daten auf Host installieren

Neueste Pakete herunterladen

Hinweis: MySQL ist nicht mehr verfügbar, es sei denn, das Oracle MySQL-Repository wird explizit in die Repository-Liste aufgenommen. MariaDB hat MySQL ersetzt.

root@uat-app:~# apt-get update
root@uat-app:~# apt-get install libmariadb-dev
root@uat-app:~# apt-get install default-mysql-server

Datenbank starten

root@uat-app:~# service mysql status
[info] MariaDB ist gestoppt..
root@uat-app:~#
root@uat-app:~# service mysql start
[ ok ] Starten des MariaDB-Datenbank-Servers: mysqld.
root@uat-app:~# service mysql status
[info] /usr/bin/mysqladmin Ver 9.1 Distrib 10.3.25-MariaDB, für debian-linux-gnu auf x86_64
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab und andere.

Serverversion 10.3.25-MariaDB-0+deb10u1
Protokollversion 10
Verbindung Localhost über UNIX-Socket
UNIX-Socket /var/run/mysqld/mysqld.sock
Laufzeit: 4 Sek

Threads: 7 Fragen: 461 Langsame Abfragen: 0 Öffnungen: 177 Tabellen leeren: 1 Offene Tabellen: 31 Abfragen pro Sekunde im Durchschnitt: 115,250.

Gems für Datenbankverbindung installieren

Im Folgenden wird gezeigt, dass das neueste „bundle“ einige der Flags in den ursprünglichen Anweisungen nicht mag und der Modus „deployment“ deaktiviert werden muss.

root@uat-app:~# echo "gem 'mysql2', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# echo "gem 'php_serialize', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle install --no-deployment --without test --without development --path vendor/bundle'
[DEPRECATED] Die Flag `--path` ist veraltet, da sie darauf angewiesen ist, über mehrere Aufrufe von Bundler hinweg gespeichert zu werden, was Bundler in zukünftigen Versionen nicht mehr tun wird. Bitte verwenden Sie stattdessen `bundle config set path 'vendor/bundle'` und nutzen Sie diese Flag nicht mehr.
[DEPRECATED] Die Flag `--without` ist veraltet, da sie darauf angewiesen ist, über mehrere Aufrufe von Bundler hinweg gespeichert zu werden, was Bundler in zukünftigen Versionen nicht mehr tun wird. Bitte verwenden Sie stattdessen `bundle config set without 'development'` und nutzen Sie diese Flag nicht mehr.
Sie versuchen, im Bereitstellungsmodus zu installieren, nachdem Sie Ihre Gemfile geändert haben. Führen Sie `bundle install` an anderer Stelle aus und fügen Sie die aktualisierte Gemfile.lock der Versionskontrolle hinzu.

Wenn dies eine Entwicklungsmaschine ist, entfernen Sie die /var/www/discourse/Gemfile-Einfrierung durch Ausführen von `bundle config unset deployment`.

Die Abhängigkeiten in Ihrer Gemfile haben sich geändert

Sie haben zur Gemfile hinzugefügt:
* mysql2
* php_serialize

Konfiguration aktualisieren und Installation erneut ausführen

Über CLI prüfen

Die Überprüfung der Konfiguration bestätigte, dass sie auf den Modus „deployment“ eingestellt ist.

root@uat-app:/var/www/discourse# bundle config list
Einstellungen sind in der Reihenfolge der Priorität aufgelistet. Der oberste Wert wird verwendet.
deployment
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): true

jobs
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): 4

retry
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): 3

path
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): "vendor/bundle"

without
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): [:development, :test]

Durch Überprüfen der Konfigurationsdatei prüfen

Im Folgenden wird dieselbe Überprüfung durch Überprüfen der Konfigurationsdatei durchgeführt.

root@uat-app:/var/www/discourse# cat /var/www/discourse/.bundle/config
---
BUNDLE_DEPLOYMENT: "true"
BUNDLE_JOBS: "4"
BUNDLE_RETRY: "3"
BUNDLE_PATH: "vendor/bundle"
BUNDLE_WITHOUT: "development:test"

Konfiguration aktualisieren

root@uat-app:/var/www/discourse# bundle config set path 'vendor/bundle'
Ihre Anwendung hat path auf "vendor/bundle" gesetzt. Dies wird den globalen Wert überschreiben, den Sie derzeit festlegen.
root@uat-app:/var/www/discourse# bundle config set without 'development:test'
Ihre Anwendung hat without auf "development:test" gesetzt. Dies wird den globalen Wert überschreiben, den Sie derzeit festlegen.
root@uat-app:/var/www/discourse# bundle config unset deployment

Konfiguration erneut validieren

root@uat-app:/var/www/discourse# bundle config list
Einstellungen sind in der Reihenfolge der Priorität aufgelistet. Der oberste Wert wird verwendet.
path
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): "vendor/bundle"
Für den aktuellen Benutzer gesetzt (/root/.bundle/config): "vendor/bundle"

without
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): [:development, :test]
Für den aktuellen Benutzer gesetzt (/root/.bundle/config): [:development, :test]

jobs
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): 4

retry
Für Ihre lokale App gesetzt (/var/www/discourse/.bundle/config): 3

Installationsversuch erneut durchführen

Führen Sie die Installation für die Gems erneut aus und verlassen Sie den Container.

root@uat-app:/var/www/discourse# su discourse -c 'bundle install'
...........
Bundle vollständig! 125 Gemfile-Abhängigkeiten, 163 Gems jetzt installiert.
Gems in den Gruppen development und test wurden nicht installiert.
Gebündelte Gems sind in `./vendor/bundle` installiert.
root@uat-app:/var/www/discourse# exit

Verzeichnis für vBulletin-Daten erstellen

Verzeichnis erstellen

[root@uat standalone]# pwd
/var/discourse/shared/standalone
[root@uat standalone]# mkdir vbulletin

vBulletin-Datenbank kopieren

[root@uat standalone]# scp <login user>@<vbulletin server IP>:/home/backup/vbulletin/vbulletin-2020-11-14-03:30:01.sql.bz2 ./vbulletin/.

vBulletin-Datenbank entpacken

[root@uat containers]# docker exec -it app bash
root@uat-app:/# cd /shared/vbulletin
root@uat-app:/shared/vbulletin# bunzip2 vbulletin-2020-11-14-03\:30\:01.sql.bz2

Datenquelle einrichten

Datenbank vb4 erstellen

root@uat-app:/shared/vbulletin# mysql -uroot -p -e 'CREATE DATABASE vb4'
Passwort eingeben:

vBulletin in MariaDB importieren

root@uat-app:/shared/vbulletin# mysql -uroot -p vb4 < vbulletin-2020-11-14-03\:30\:01.sql
Passwort eingeben:

Profilarchive entpacken

[root@uat vbulletin]# tar xvfz signaturepics.tar.gz
[root@uat vbulletin]# tar xvfz customavatars.tar.gz
[root@uat vbulletin]# tar xvfz customprofilepics.tar.gz

Root-Passwort der Datenbank aktualisieren

root@uat-app:/var/www/discourse# mysql -uroot -p
Passwort eingeben:
Willkommen im MariaDB-Monitor. Befehle enden mit ; oder \g.
Ihre MariaDB-Verbindungs-ID ist 77
Serverversion: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab und andere.

Geben Sie 'help;' oder '\h' für Hilfe ein. Geben Sie '\c' ein, um den aktuellen Eingabebefehl zu löschen.

MariaDB [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED BY '1234';
Abfrage OK, 0 Zeilen betroffen (0,001 Sek)

MariaDB [(none)]> quit
Bye

In Discourse importieren

Verbindungsdetails der Datenquelle festlegen

[root@uat vbulletin]# export DB_NAME="vb4"
[root@uat vbulletin]# export DB_USER="root"
[root@uat vbulletin]# export DB_PW="1234"
[root@uat vbulletin]# export TABLE_PREFIX="vbulletin"
[root@uat vbulletin]# export ATTACHMENT_DIR='/shared/vbulletin'
[root@uat vbulletin]# export TIMEZONE="America/Vancouver"
[root@uat vbulletin]# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost möchte vb4
Vorhandene Gruppen werden geladen...
Vorhandene Benutzer werden geladen...
Vorhandene Kategorien werden geladen...
Vorhandene Beiträge werden geladen...
Vorhandene Themen werden geladen...

Importieren von Gruppen...
15 / 15 (100,0%) [3272 Elemente/Min] n]
Importieren von Benutzern
117 / 11033 ( 1,1%) [145 Elemente/Min] in]

Das Problem bei deiner ersten Verbindung zur Datenbank war also, dass Bibliotheken vermischt wurden?

Das glaube ich nicht. Ich habe das Passwort gerade explizit geändert, und es konnte ausgeführt werden. Jetzt habe ich ein Problem beim Importieren privater Nachrichten. Ich sehe sehr häufig Folgendes. Haben Sie eine Idee, was das sein könnte?

Importiere private Nachrichten...
      139 / 177409 (  0.1%)  [399 Einträge/min]  eine der Teilnehmer-IDs ist nil -- [nil, 270]
pm-149 hat kein Ziel (a:1:{i:486;s:5:"TonyN";})
      364 / 177409 (  0.2%)  [418 Einträge/min]  eine der Teilnehmer-IDs ist nil -- [nil, 276]
pm-420 hat kein Ziel (a:1:{i:623;s:14:"the other side";})
      571 / 177409 (  0.3%)  [414 Einträge/min]  eine der Teilnehmer-IDs ist nil -- [nil, 445]
pm-702 hat kein Ziel (a:1:{i:767;s:6:"greatg";})
      572 / 177409 (  0.3%)  [414 Einträge/min]  eine der Teilnehmer-IDs ist nil -- [nil, 445]
      605 / 177409 (  0.3%)  [416 Einträge/min]  eine der Teilnehmer-IDs ist nil -- [nil, 461]

Entweder wurden diese Benutzer aus irgendeinem Grund nicht importiert (fehlende E-Mail-Adresse war eine Ursache, aber das sollte jetzt behoben sein), oder aus einem anderen Grund funktioniert der Code, der importierte Benutzernamen nachschlägt, nicht (vielleicht die Groß-/Kleinschreibung des Benutzernamens?).

@pfaffman Ja, das sieht tatsächlich so aus, auch wenn einige Details noch unklar sind. Schauen wir uns zum Beispiel den ersten Fall an.

1. Was bedeutet pm-149?
2. Bei a:1:{i:486;s:5:"TonyN";} sieht der Text “TonyN” wie ein Benutzername aus, aber was bedeuten die anderen Zahlen?
3. Wie sieht es mit [nil, 270] aus? Was bedeutet die 270?

Wenn ich verstehe, worüber es sich beschwert, kann ich zumindest versuchen, die Datenbank zu prüfen, um festzustellen, ob es Datenprobleme gibt. Aber ich bin mir nicht sicher, was diese Werte wirklich bedeuten.

Übrigens habe ich auch bemerkt, dass alle importierten Foren Berechtigungen für alle Benutzer haben. Das bedeutet, dass Foren, die nur für Moderatoren zugänglich sein sollten, nun für alle sichtbar sind. Gibt es eine Möglichkeit, das zu steuern?

Entschuldigung. Ich kann mich nicht mehr genau genug erinnern, um es zu erklären. Das ist im Grunde die gesamte kostenlose Hilfe, die ich dazu anbieten kann.

Natürlich. Siehe Understanding groups and category permissions

Einige Importeure bemühen sich, Gruppen zu importieren, aber nur wenige wissen, wie man diese Berechtigungen auf die importierten Kategorien anwendet. Du musst diese manuell korrigieren.

Nach den Anweisungen von @titusc habe ich Probleme beim Importieren der Datenbank…

root@DO-Discourse-app:/shared/vbulletin# mysql -uroot -p vb4 < CC12-Sat-Full-Backup.sql
Passwort eingeben:
ERROR 1265 (01000) in Zeile 4928: Daten für Spalte 'method' in Zeile 1 abgeschnitten
root@DO-Discourse-app:/shared/vbulletin#

Habt ihr einen Tipp, wonach es sucht?

N/M – Es sind Fehler in der ursprünglichen Datenbank.