baumaschinenteile24
Sehr aktives Mitglied
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:
Währenddessen hat die DB ständig Abfragen der Art
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.
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:
Das ganze jeweils mit mehreren solcher array keys."mod_fcgid: stderr: PHP Warning: Undefined array key "bilder_merkmalwert_mini_hoehe" in /.../Media/Image.php on line 152",
Währenddessen hat die DB ständig Abfragen der Art
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.SELECT cPfad AS path FROM tkategoriepict WHERE kKategorie = 738 LIMIT 1
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.