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

  • Betroffene Version
    WoltLab Suite 5.5

    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!

    Einmal editiert, zuletzt von Tassja (14. April 2022 um 20:23) aus folgendem Grund: PHP-Version eingefügt.

  • 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)

    • Offizieller Beitrag

    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.

    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?

  • 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.

    • Offizieller Beitrag

    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?

    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.

  • 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.

  • 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:

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

    Einmal editiert, zuletzt von Tassja (15. April 2022 um 08:00)

  • 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:

    • Offizieller Beitrag

    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 ;)

  • 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:


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

  • 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.

  • 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.

  • 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.

    • Offizieller Beitrag

    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 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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!