Upgrade von BlueSpice 3 auf BlueSpice 4 schlägt fehl

Describe the issue / Steps to reproduce:
Beim migrieren von BlueSpice 3.0.1 (MediaWiki 1.31.2) auf Version 4.3.3 bleibt es an einer Stelle immer hängen und es geht nicht weiter. Bei diesem Schritt geht es nicht weiter:
Query: SELECT DISTINCT rev_id,rev_timestamp,rev_sha1,actor_rev_user.actor_user AS rev_user,actor_rev_user.actor_name AS rev_user_text,rev_actor FROM mw_archive,mw_revision JOIN mw_actor actor_rev_user ON ((actor_rev_user.actor_id = rev_actor)) WHERE (ar_rev_id >= 2) AND (ar_rev_id <= 10001)
Function: DeduplicateArchiveRevId::doDBUpdates

Expected behavior:
A clear description of what you expected to happen.

What was the error message/error log?
Did the screen show an error? Did you look at any error logs? This info will speed up the solution process.

Screenshots
Siehe Screenshot der Konsole.
Screenshot

System info:
view system requirements

  • OS: Ubuntu 22.04.3 LTS
  • Server: Apache/2.4.58 (Ubuntu)
  • PHP: PHP 7.4.33
  • Database: 10.11.6-MariaDB-1:10.11.6+maria~ubu2204
  • BlueSpice version: BlueSpice free 4.3.3
  • Browser version: Chrome version 120.0.6099.71

Im mysql prozess sieht diesen Schritt auch (siehe Screenshot2).

Gibt es Ideen was man da machen kann?

Bin nach der Anleitung von hier vorgegangen:
https://de.wiki.bluespice.com/wiki/Setup:Installationsanleitung/Upgrade

Dies kommt bei dem Schritt:
php maintenance/update.php --quick

Willkommen im BlueSpice Community Forum!

Können Sie bitte mal auf der Datebank-Konsole die folgende Abfrage ausführen und das Ergebnis hier teilen?

EXPLAIN
    SELECT DISTINCT 
        rev_id,
        rev_timestamp,
        rev_sha1,
        actor_rev_user.actor_user AS rev_user,
        actor_rev_user.actor_name AS rev_user_text,
        rev_actor
    FROM
        mw_archive,
        mw_revision
    JOIN mw_actor actor_rev_user 
        ON ((actor_rev_user.actor_id = rev_actor)) 
    WHERE (ar_rev_id >= 2)
        AND (ar_rev_id <= 10001);

Guten Morgen, im Anhang das Ergebnis:

Danke. Das Ergebnis sieht zunächst recht unauffällig aus. Es sind natürlich relativ viele Revisionen, so dass die Operation durchaus eine Zeit lang dauern kann.

Ich würde empfehlen ein zweischrittiges Update zu versuchen. Zur Erklärung: BlueSpice 3 verwendete MediaWiki 1.31, BlueSpice 4 zunächst MediaWiki 1.35, dann 1.39. Zwischen MediaWiki 1.31 und MediaWiki 1.39 liegen einige Umbauten im Datenbankschema. Zwar funktioniert das Update von 1.31 auf 1.39 im allgemeinen, es werden aber auch immer wieder Probleme berichtet.

Bitte zunächst mal ein MediaWiki 1.35 herunterladen und mit der DB verbinden. Dann darin die maintenance/update.php ausführen. Anschließend BlueSpice 4 mit MediaWiki 1.39 anbinden und erneut maintenance/update.php ausführen.

Achja und vor dem Update auf 1.35 bitte auch noch php maintenance/cleanupUsersWithNoId.php --prefix=deleted ausführen.

Guten morgen und frohes neues Jahr :slight_smile:

@rvogel Robert mit dem Zwischenschritt hat es endlich funktioniert :wink:
Vielen Dank.

Ticket kann geschlossen werden.

Hallo Robert, leider scheinen einige Seiten nach der Migration nicht mehr zu funktionieren. Beim Aufrufen von z.B. der Seite “Office 2013” kommt folgende Fehlermeldung (siehe Screenshot Office_2013_01.png)

Versuche ich die Seite zu Bearbeiten oder Quelltext bearbeiten kommt die Fehlermeldung (siehe Screenshot Office_2013_02.png)

Versuche ich neuen Abschnitt hinzuzufügen kommt die Fehlermeldung (siehe Screenshot Office_2013_03.png)

Löschen lässt sich die Seite auch nicht (siehe Screenshot Office_2013_04.png)

Dies betrifft ziemlich genau 5 Seiten, ist zwar überschaubar und ich kann mir die Seiten von der alten Version ziehen, aber die Seiten lassen sich nicht mal löschen… haben Sie eine Idee wie ich die Seiten löschen kann? Ggf. direkt auf der Datenbank?!?

Danke.

Vermutlich hängt dies mit der sog. “Actors Migration” zusammen. Wurde denn im Vorfeld maintenance/cleanupUsersWithNoId.php --prefix=deleted ausgeführt (s.o.)?

Wenn es sich nur um wenige Seiten handelt lohnt es nicht die Migration erneut durchzuführen.

Man kann die rev_actor Spalte der revision Tabelle ggf. manuell korrigieren.

Dazu ermittelt man zunächst die page_id aus der Tabelle page, dann alle Revisionen mittels rev_page-Fremdschlüssel aus der revision Tabelle und korrigiert alle rev_actor Werte, welche in der actors Tabelle nicht sauber auf einen Eintrag in der user Tabelle verweisen.

Hallo Herr Vogel, das klingt gut. Leider habe ich sehr wenig Ahnung mit mySQL :frowning: Hätten Sie dazu die passenden Konsolen Befehle?

Danke.

Hallo Herr Vogel, ein mySQL Datenbankexperte konnte mir helfen :slight_smile: Seiten sind nun wieder “repariert”.

Danke.

1 Like