dbupdater Skript läuft nach Update von 4.0.6 auf 5.1.2 nicht durch

baumaschinenteile24

Sehr aktives Mitglied
2. Mai 2012
377
57
Bei uns ist folgende Situation aufgetreten:

Wir versuchen, von JTl-Shop 4.06 auf 5.2.1 zu updaten. Ich habe vor ein paar Wochen eine Kopie der Seite erstellt und dann das Update testweise auf dieser Kopie laufen lassen.
Anfangs ging nach dem Installieren der Shopdateien gar nichts, aber nachdem ich die admin/.htaccess angepasst hatte und den Speicher für PHP-Skripte auf 512MB erhöht hatte, konnte ich mich im Backend anmelden und dann lief das dbupdater-Skript auch problemlos durch.

Letzte Woche habe ich das im Live-System versucht, diesmal gleich mit aktualisierter .htaccess und erhöhtem Speichervolumen, und dieses Mal fing das dbupdater Skript auch gut an, aber mittendrin gab es dann ein Problem: die Datenbank-Engine war voll ausgelastet und es gab so viele PHP-Warnmeldungen, dass das Errorlog völlig ausgeufert ist. Die Fehler sahen so aus:
"mod_fcgid: stderr: PHP Warning: Undefined array key "bilder_merkmalwert_mini_hoehe" in /.../Media/Image.php on line 152",
Das ganze jeweils mit mehreren solcher array keys.
Währenddessen hat die DB ständig Abfragen der Art
SELECT cPfad AS path FROM tkategoriepict WHERE kKategorie = 738 LIMIT 1
durchgeführt. Das klingt jetzt für mich erstmal so, als ginge es bei dem Vorgang um die Kategoriebilder. Nun haben bei uns die Kategorien eigentlich keine Bilder, aber das sollte das Skript ja nicht stören, Kategorien ohne Bild werden ja viele Shops haben. Wir haben jetzt recht viele Kategorien (ca. 25.000), aber das war ja im Testsystem nicht anders und hat da nicht gestört. Das Update wurde auch nicht abgebrochen, aber es wurde eben auch nicht fertig, so dass wir auf die 4.0.6 zurückgegangen sind. Die läuft, aber eine zukunftsfähige Lösung ist das natürlich nicht. Jetzt wollen wir uns nicht nochmal den Stress machen, das Update durchzuführen, wenn wir nicht sicher wissen, dass es laufen wird. Daher erstmal die Frage: hat noch jemand dieses Phänomen erlebt und hat eine Lösung dafür? Oder kann sich wenigstens vorstellen, woher diese Fehlermeldungen kommen? Undefinierte Arrays klingt erstmal nach einem Fehler im Skript. Dagegen könnten wir ja von uns aus wenig tun.

Von daher kommen für mich jetzt erstmal folgende Lösungen in Frage:
1. Wir sind ja in der etwas frustigen Situation, ein Testsystem zu haben, auf dem die 5.2.1 läuft, das aber natürlich von den Daten her nicht aktuell ist, während das aktuelle System nicht updatet. Ich habe beim Anlegen des Testservers schon eine Weile gebraucht bis alles lief und in der Zeit lief ja das Live-System weiter. Seitdem sind noch ein paar Wochen vergangen. Technisch wäre es ja kein Problem, den Domain-Namen vom Live-System auf das Testsystem zu übertragen und nahtlos weiterzuarbeiten, inhaltlich haut das aber nicht hin. Nun stellt sich mir die Frage: was passiert, wenn ich jetzt die aktuelle Datenbank aus dem Live-System in das Testsystem kopiere, in der Config diese Kopie als Shopdatenbank setze und den dbupdater nochmal drüberlaufen lasse? Währenddessen könnte das Livesystem ja im Wartungsmodus bleiben, damit sich dort nichts tut. Vorausgesetzt der Updater läuft im Testsystem auch diesmal einwandfrei durch, hätte ich dann doch eine korrekte, aktuelle Version von unserem Shopsystem, oder übersehe ich da etwas? Eventuell fehlende Artikelbilder würde der Shopabgleich ja nachliefern. Dann lasse ich Plesk den Domainnamen mit dem bisherigen Testsystem verbinden und fertig. Nun rät JTL ja immer davon ab, den Shop neu zu installieren und dann mit einer existierenden Datenbank zu beschicken, aber das wäre ja hier auch nicht der Fall. Mir ist schon klar, dass ein Update eines aktuellen Systems tendenziell vorzuziehen ist. Aber wir haben jetzt schon einen ziemlich stressigen und zeitaufwendigen Fehlschlag durch, da wäre es schön, eine Alternative zu haben. Hat das eventuell jemand probiert und kann mir sagen, ob ich irgendwelche Fallstricke übersehe?

2. Es gibt ja mittlerweile eine Shop-Version 5.2.2. Hat sich da am dbupdater Script irgendetwas signfikantes geändert? Dann wäre es ja vielleicht sinnvoll, statt auf die 5.2.1 auf die 5.2.2 zu updaten.

3. Umgekehrt könnte man erwägen, auf eine frühere Version des 5er Shops zu updaten und dann von da die aktuelleren Änderungen einzuspielen. Das hätte dann ja den Effekt, dass man die Datenbank-Updates eben schrittweise macht, ich sag mal 4.0.6->5.0.3->5.2.2. Die Frage ist, bringt das konzeptionell irgendwas? Oder passiert datenbankseitig gar nicht mehr so viel zwischen 5.0.x und und 5.2.x? Beziehungsweise sind die Update-Skripte der älteren Versionen eventuell auch weniger stabil als die neueren?

Ich bin aktuell etwas ratlos, wie ich am besten weiter verfahren sollte und wäre für alle Tipps dankbar. Option 1 ließe sich ja relativ unumständlich ausprobieren, erscheint mir aber am wenigsten aussichtsreich.
 

baumaschinenteile24

Sehr aktives Mitglied
2. Mai 2012
377
57
Anderer Gedanke: kann man, statt dbupdater.php auszuführen, auch die Migrations-Skripte einzeln ausführen? Also sprich, macht das Skript noch irgendetwas außer die Migrations-Skripte nacheinander aufzurufen? Das ist zwar etwas umständlich, aber dann würde ich besser sehen, welche Skripte sauber ablaufen und wo der Fehler passiert. Dann könnte man sich das Skript nochmal vorknöpfen und hoffentlich sehen, was den Fehler verursacht hat, das Problem beheben und das Update zu Ende bringen.
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
6.937
1.707
Berlin
genau das macht der Updater doch, er gibt dir einen Fehler und dann schaust du was er möchte.

Ich mache hierbei immer die Browser Console auf und schaue unter Netzwerk was er macht und wenn ich sehe das etwas aus dem Ruder läuft dann schaue ich was da los ist.

Man muss hier echt, je nach Problem anders handeln, ist es ein Migrationsscript was eine hohe DB Last hat oder kein Ende findet schaue ich über phpmyadmin was da für querys laufen, ist es eine Fehlermeldung die SQL betrifft dann schaue ich was die wollen und behebe das Problem.

Es gibt diverse Schritte die je nach DB locker drei Tage benötigen könnten.

Wie angesprochen, das muss immer individuell gelöst werden, es gibt hier kein Handbuch mit Lösungsvorschlägen wie bei einer defekten Waschmaschine.
 

baumaschinenteile24

Sehr aktives Mitglied
2. Mai 2012
377
57
Verstehe ich alles, aber den Shop tagelang abzuschalten und dran herumzudoktern ist jetzt auch nicht gerade eine verlockende Aussicht. Erstmal danke für alle Hinweise und Einsichten, irgendwie kriegen wir das schon gelöst.
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
6.937
1.707
Berlin
In deinem Fall (weil du schreibst das es beim ersten Versuch ja geklappt hat) nochmal eine Kopie des Shops erstellen und das erneut in einer Dev Umgebung versuchen, hierzu würde ich dann einen SP hinzuziehen der schaut was das eigentliche Problem ist, es gibt Querys in der Migration, die erfordern in Verbindung mit Mariadb, das die Tabellen zwischendurch optimiert werden, das betrifft insbesondere die Preistabelle die gerne mal stress verursacht.

Ein SP geht diese Probleme ja ganz anders an und kann Querys im Zweifelsfall auch umschreiben oder umgehen wenn Sie stören bzw. im internen Chat mit den Programmierern direkt sprechen wenn ein Migrationsschritt sorgen macht.

Ich z.B. ziehe so einen Shop in der Regel auf meinen Developer Server um dort ein Test Update zu machen, hierbei notiere ich dann alle Anpassungen die eventuell erforderlich sind, wenn das alles klar ist dann update ich so ein Live System über Nacht und weiß in der Regel was mich erwartet.