Woltlab Migration per Kommandozeile (CLI) - Anzeigen aktualisieren Skript schlägt fehlt

Tassja · Apr 14th 2022

Nabend zursammen!

Nach einen recht umfangreichen Import von Burning Board 4.1 auf die aktuelle Version der WoltlabSuite (5.4.1) schlägt nun gleich das erste Skript zur Aktualisierung der Anzeigen fehl.

Auf dem Server ist PHP 7.4.28 ist Einsatz.

Unmittelbar nachdem ich dieses Skript in der CLI-Session eingebe:

Code

worker wcf\\system\\worker\\LikeRebuildDataWorker

kommt gleich dieser Fehler:

Code

[ERROR]
wcf\system\exception\ErrorException: Trying to get property 'reactionTypeID' of non-object in /var/www/vhosts/domain.com/httpdocs/lib/system/WCF.class.php:344
Stack trace:
#0 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/LikeRebuildDataWorker.class.php(89): wcf\system\WCF::handleError()
#1 /var/www/vhosts/domain.com/httpdocs/lib/system/cli/command/WorkerCLICommand.class.php(160): wcf\system\worker\LikeRebuildDataWorker->execute()
#2 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(336): wcf\system\cli\command\WorkerCLICommand->execute()
#3 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(94): wcf\system\CLIWCF->initCommands()
#4 /var/www/vhosts/domain.com/httpdocs/cli.php(21): wcf\system\CLIWCF->__construct()
#5 {main}

Ich will nichts falsch machen und deswegen habe ich dieses und bisher kein weiteres Skript ausprobiert.

Daher meine Fragen:

Wenn ein Skript einen Fehler wirft, kann ich mit den anderen Skripten weiter machen?

Vom Namen her tippe ich auf irgend etwas mit dem Like-System. Es gibt wohl in der Datenbank auch eine Tabelle mit Likes (wcf1_like)

Wer kenn kann bitte helfen - ich will da keine Fehler machen.

Herzliche Grüße und vielen Dank im Voraus!

**Alexander Ebert** · Apr 14th 2022

Quote from Tassja

5.4.1

Wirklich auf die Version 5.4.1 oder tatsächlich eine neuere?

Tassja · Apr 14th 2022

Oh sorry - ist die Version 5.4.15

Ich hatte bei meiner Angabe die "5" hinter der "1" vergessen.

Bitte vielmals um Entschuldigung.

Generell kann etwas mit diesen Aktualisierungs-Skripten "zerschossen" werden?

Habe den Import per CLI nun seit 5 Tagen am Laufen gehabt und will möglichst vermeiden, da nun nochmal das Ganze zu wiederholen (habe aber auch schon Backups von der aktuellen Datenbank und dem gesamten httpsdocs-Verzeichnis gemacht)

**Alexander Ebert** · Apr 14th 2022

Quote from Tassja

Generell kann etwas mit diesen Aktualisierungs-Skripten "zerschossen" werden?

Nein, aber mich wundert die Fehlermeldung nach einem Import doch sehr, das ergibt für mich keinen Sinn.

Quote from Tassja

Habe den Import per CLI nun seit 5 Tagen am Laufen gehabt und will möglichst vermeiden, da nun nochmal das Ganze zu wiederholen (habe aber auch schon Backups von der aktuellen Datenbank und dem gesamten httpsdocs-Verzeichnis gemacht)

5 Tage?! Wie viele Hundert Millionen Beiträge hat denn das Forum, dass das so extrem lange dauert?

Tassja · Apr 14th 2022

Die Zahl der Beiträge liegt bei 310.336 - also eigentlich überschaubar. Die Datenbank selbst sind 1,59 GB.

Mir kam das auch extrem langsam vor, nur weiss ich nicht, was bei den Skript da genau (im Hintergrund) passiert.

So rein von der Datenbank sieht von den Tabellen her alles recht vernünftig aus - also wenn ich in phpMyAdmin rein sehe.

Vielleicht lag die Verzögerung des Imports auch ein wenig daran, dass ich beim Benutzerimport auf Mail oder Name prüfen und zusammen legen soll - also Option 2, statt 1.

**Alexander Ebert** · Apr 14th 2022

Quote from Tassja

Die Zahl der Beiträge liegt bei 310.336 - also eigentlich überschaubar. Die Datenbank selbst sind 1,59 GB.

Ein Import in der Größenordnung sollte innerhalb von ~2 Stunden durch sein, da stimmt etwas ganz gewaltig nicht beim Server. Was ist denn das für ein System, das so extrem lahm ist?

Quote from Tassja

Vielleicht lag die Verzögerung des Imports auch ein wenig daran, dass ich beim Benutzerimport auf Mail oder Name prüfen und zusammen legen soll - also Option 2, statt 1.

Nein, das hat keine Auswirkungen.

Tassja · Apr 14th 2022

Vom Server her sollte das eigentlich ausreichen ....

Intel Xeon CPU E3-1230 v3 3.30GHz (8Core)

Ubuntu 20.04.4 LTS

Speicher: 32GB

HDD: 2TB

Für das Forum also die "Domain" habe ich bei PHP 256MB Speicher als Memory-Limit

Und da läuft noch ne Juggernaut Firewall drauf.

Tassja · Apr 15th 2022

Ich habe nun die Firewall mal ausgeschaltet und bekomme bei erneuter Eingabe des ersten Skriptes zur Aktualisierung (worker wcf\\system\\worker\\LikeRebuildDataWorker) nun folgende Meldung:

Code

>worker wcf\\system\\worker\\LikeRebuildDataWorker
[ERROR]
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away in /var/www/vhosts/domain.com/httpdocs/lib/system/database/Database.class.php:328
Stack trace:
#0 /var/www/vhosts/domain.com/httpdocs/lib/system/database/Database.class.php(328): PDO->prepare()
#1 /var/www/vhosts/domain.com/httpdocs/lib/data/DatabaseObjectList.class.php(153): wcf\system\database\Database->prepareStatement()
#2 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/AbstractRebuildDataWorker.class.php(75): wcf\data\DatabaseObjectList->countObjects()
#3 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/AbstractWorker.class.php(65): wcf\system\worker\AbstractRebuildDataWorker->countObjects()
#4 /var/www/vhosts/domain.com/httpdocs/lib/system/cli/command/WorkerCLICommand.class.php(131): wcf\system\worker\AbstractWorker->getProgress()
#5 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(336): wcf\system\cli\command\WorkerCLICommand->execute()
#6 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(94): wcf\system\CLIWCF->initCommands()
#7 /var/www/vhosts/domain.com/httpdocs/cli.php(21): wcf\system\CLIWCF->__construct()
#8 {main}

Next wcf\system\database\exception\DatabaseQueryException: Could not prepare statement 'SELECT  COUNT(*)
                FROM    wcf1_like like_table

                ' in /var/www/vhosts/domain.com/httpdocs/lib/system/database/Database.class.php:333
Stack trace:
#0 /var/www/vhosts/domain.com/httpdocs/lib/data/DatabaseObjectList.class.php(153): wcf\system\database\Database->prepareStatement()
#1 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/AbstractRebuildDataWorker.class.php(75): wcf\data\DatabaseObjectList->countObjects()
#2 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/AbstractWorker.class.php(65): wcf\system\worker\AbstractRebuildDataWorker->countObjects()
#3 /var/www/vhosts/domain.com/httpdocs/lib/system/cli/command/WorkerCLICommand.class.php(131): wcf\system\worker\AbstractWorker->getProgress()
#4 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(336): wcf\system\cli\command\WorkerCLICommand->execute()
#5 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(94): wcf\system\CLIWCF->initCommands()
#6 /var/www/vhosts/domain.com/httpdocs/cli.php(21): wcf\system\CLIWCF->__construct()
#7 {main}

Display More

In der Error-Log-Datei von MySQL unter /var/log/mysql/error.log ist leider nichts zu finden.

Tassja · Apr 15th 2022

Zur Hilfe hier mal das Ergebnis, wenn ich in der bash folgenden Befehl eingebe:

Code

mysqld --print-defaults

Und hier die Ausgabe (etwas sortiert, da normal alles hintereinander weggeschrieben wird:

Code

--user=mysql 
--pid-file=/run/mysqld/mysqld.pid 
--socket=/run/mysqld/mysqld.sock 
--basedir=/usr 
--datadir=/var/lib/mysql 
--tmpdir=/tmp 
--lc-messages-dir=/usr/share/mysql 
--bind-address=127.0.0.1 
--query_cache_size=16M 
--log_error=/var/log/mysql/error.log 
--expire_logs_days=10 
--character-set-server=utf8mb4 
--collation-server=utf8mb4_general_ci 
--sql_mode=ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION 
--bind-address=::ffff:127.0.0.1 
--local-infile=0

Display More

**Alexander Ebert** · Apr 15th 2022

Hallo,

der Server ist selbst für HDDs ungewöhnlich langsam. Auch wenn die CPU aus 2013 stammt, so hat die eigentlich genug Leistung, MySQL scheint hier ganz massiv zu bremsen. Es dürfte helfen, innodb_flush_log_at_trx_commit = 2 zu setzen und so die Last auf der Festplatte zu reduzieren.

Dessen ungeachtet würde ich empfehlen, auf ein moderneres System zu wechseln. Selbst der Wechsel von HDD auf SSD ist insbesondere bei MySQL ein „Quantensprung“, das ist eine deutliche Mehrleistung, die auch im laufenden Betrieb bemerkbar ist. Nicht ohne Grund haben wir bei unserem Cloud-Hosting von Anfang an auf 100% SSD-Speicher gesetzt

Tassja · Apr 15th 2022

Danke für den Hinweis - das mit der Empfehlung zum SSD-System wusste ich nicht.

Den Wert innodb_flush_log_at_trx_commit = 2 habe ich in der my.cnf empfehlungsgemäß abgeändert und den mysql-server neu gestartet.

Nichtsdestotrotz bekomme ich immer noch diesen Fehler wenn ich den ersten Skript zur Aktualisierung starten will:

Code

>worker wcf\\system\\worker\\LikeRebuildDataWorker
[ERROR]
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away in /var/www/vhosts/domain.com/httpdocs/lib/system/database/Database.class.php:328
Stack trace:
#0 /var/www/vhosts/domain.com/httpdocs/lib/system/database/Database.class.php(328): PDO->prepare()
#1 /var/www/vhosts/domain.com/httpdocs/lib/data/DatabaseObjectList.class.php(153): wcf\system\database\Database->prepareStatement()
#2 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/AbstractRebuildDataWorker.class.php(75): wcf\data\DatabaseObjectList->countObjects()
#3 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/AbstractWorker.class.php(65): wcf\system\worker\AbstractRebuildDataWorker->countObjects()
#4 /var/www/vhosts/domain.com/httpdocs/lib/system/cli/command/WorkerCLICommand.class.php(131): wcf\system\worker\AbstractWorker->getProgress()
#5 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(336): wcf\system\cli\command\WorkerCLICommand->execute()
#6 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(94): wcf\system\CLIWCF->initCommands()
#7 /var/www/vhosts/domain.com/httpdocs/cli.php(21): wcf\system\CLIWCF->__construct()
#8 {main}

Next wcf\system\database\exception\DatabaseQueryException: Could not prepare statement 'SELECT  COUNT(*)
                FROM    wcf1_like like_table

                ' in /var/www/vhosts/domain.com/httpdocs/lib/system/database/Database.class.php:333
Stack trace:
#0 /var/www/vhosts/domain.com/httpdocs/lib/data/DatabaseObjectList.class.php(153): wcf\system\database\Database->prepareStatement()
#1 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/AbstractRebuildDataWorker.class.php(75): wcf\data\DatabaseObjectList->countObjects()
#2 /var/www/vhosts/domain.com/httpdocs/lib/system/worker/AbstractWorker.class.php(65): wcf\system\worker\AbstractRebuildDataWorker->countObjects()
#3 /var/www/vhosts/domain.com/httpdocs/lib/system/cli/command/WorkerCLICommand.class.php(131): wcf\system\worker\AbstractWorker->getProgress()
#4 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(336): wcf\system\cli\command\WorkerCLICommand->execute()
#5 /var/www/vhosts/domain.com/httpdocs/lib/system/CLIWCF.class.php(94): wcf\system\CLIWCF->initCommands()
#6 /var/www/vhosts/domain.com/httpdocs/cli.php(21): wcf\system\CLIWCF->__construct()
#7 {main}

Display More

Tja da steh ich nun und bin a bisser'l ratlos.

**Alexander Ebert** · Apr 15th 2022

Die Fehlermeldung besagt, dass die Verbindung unerwartet durch den MySQL-Server geschlossen wurde, nicht aber weshalb. Hier müssten entsprechende Protokolle von MySQL überprüft (und ggf. aktiviert) werden, um die Ursache weiter einzugrenzen.

Tassja · Apr 15th 2022

In der Error-log finde ich nur Einträge über den Restartprozess der Datenbank - aber später nach dem erfolgreichen Start sind keine Einträge zu sehen, weshalb die Datenbank das Skript nicht ausführen will.

Black Rider · Apr 15th 2022

Auf meinem System ist die Liste bei --print-defaults wesentlich länger und umfasst praktisch meine gesamte Konfiguration. Daher würde ich daraus schließen, dass das in deinem Fall die gesamte Konfiguration des MySQL-Servers ist und damit so ziemlich eine Standardkonfiguration läuft.

Daher würde ich dir zumindest mal empfehlen, innodb_buffer_pool_size auf einen sinnvollen Wert zu setzen, sodass die Daten idealerweise vollständig im Arbeitsspeicher vorgehalten werden und damit die Geschwindigkeit der HDDs zumindest nicht mehr so stark limitiert.

Tassja · Apr 15th 2022

Das denke ich auch, aber ich habe bisher auch nicht damit gerechnet, dass spezielle Anpassungen am Server vorgenommen werden müssen.

Ich spiele eventuell mit dem Gedanken, auf ein System mit SSD umzusteigen.

Doch andererseits frage ich mich, ob dann da womöglich nicht ähnliche Probleme auftreten.

Gibt es bestimmt Empfehlungen seitens Woltlab, welches Ausstattungen ein System haben sollte.

Ebenso auch, inwiefern bei der Datenbank bestimmte Anpassungen vorgenommen werden müssen.

**Alexander Ebert** · Apr 15th 2022

Wird der Server den für etwas anderes als nur das Forum verwendet?

Tassja · Apr 15th 2022

Der Server soll nur für das Forum verwendet werden.

**Alexander Ebert** · Apr 15th 2022

Dann wäre möglicherweise das von uns angebotene Cloud-Hosting eine Alternative. Hohe Performance und Zuverlässigkeit, wir kümmern uns um alles technische inklusive Updates und die Lizenzen sind auch bereits inklusive (+ Elasticsearch für die Suche!). Wir übernehmen auch Dinge wie einen ordnungsgemäßen Import samt der Aktualisierung der Anzeigen.

Gerne können wir dies im Rahmen eines Tickets näher besprechen und so eine passende Lösung finden?

Tassja · Apr 15th 2022

Vielen Dank für das Angebot, doch preislich sprengt das leider mein Budget.

Analog · Apr 19th 2022

Tassja probiere mal folgende my.cnf zu erstellen.

bei mysql

Code

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/ 
[mysqld]
innodb-flush-log-at-trx-commit = 2
sql_mode=''
bind-address = ::ffff:127.0.0.1
local-infile=0

bei mariadb

Code

!includedir /etc/mysql/conf.d/
!includedir /etc/mariadb.conf.d/
[mysqld]
innodb-flush-log-at-trx-commit = 2
sql_mode=''
bind-address = ::ffff:127.0.0.1
local-infile=0

Vielleicht hilft das

Woltlab Migration per Kommandozeile (CLI) - Anzeigen aktualisieren Skript schlägt fehlt

Participate now!

Share

Tags