Neu Probleme beim Update von 5.2.4 auf 5.3.3

[MrS]

Hallo,

ich habe gestern ein Update des Shops von 5.2.4 auf 5.3.3 gemacht. Ich hatte dabei ein komisches Problem, dass aber gelöst ist. Ich möchte aber trotzdem darüber berichten, weil ich eine (richtige) Lösung dafür haben möchte bzw. die Ursache kennen möchte .

Folgendes ist passiert:

Ich habe alle Vorbereitungen gemacht und bin nach dem Guide vorgegangen. Sicherungen, Dateien aus den Update-Dateien gelöscht etc. Dann habe ich die Shop-Dateien hochgeladen. Lief bis dahin alles gut.

Ich habe mich dann am Backend angemeldet und sollte das Datenbankupdate starten. Gesagt, getan. Die ersten Meldungen kamen und nach etwa 3 erfolgreichen Operationen ging es nicht weiter. Ich habe ca 30 Minuten gewartet, aber es passierte nichts. Dann habe ich die Seite aktualisiert und es kam wieder die Meldung, dass ich das Datenbankupdate starten sollte. Also ein weiterer Klick auf den Button. Wieder 3 erfolgreiche Einträge (nach wenigen Sekunden), aber andere als vorher. Wieder Stillstand. Dann habe ich die Seite wieder neu geladen und das Spiel begann von vorne. Dann habe ich die Seite in Chrome (vorher Firefox) geladen und mich dort angemeldet. Und wieder das gleiche Spiel. Update starten, 3 erfolgreiche Einträge, Stillstand. Ich habe es dann etwa 10 Mal wiederholt und dann wurde angezeigt, dass das Update erfolgreich war und das Backend wurde geladen.

Dann habe ich unter Fehlerbehebund die Diagnose gemacht und gesehen, dass eine Datenbankmigration erforderlich ist. Auch hier habe ich im automatischen Modus den Vorgang gestartet. Und was soll ich sagen? Das Verhalten war das gleiche wie vorher bei dem Update.

Ich habe dann im manuellen Modus geschaut. Dort sah ich, dass die Kollation falsch ist. Die habe ich dann erst mal in PhpMyAdmin entsprechend der Liste geändert. Dann gab es noch ein paar weitere Anzeigen, die ich dann nach und nach mit der manuellen Migration beheben konnte, so das der Shop problemlos läuft.

Woran liegt das? Und was kann ich beim nächsten Update machen?

VG
Stephen

 

[css-umsetzung]

Ich mache Updates grundsätzlich über Chrome, mit offener console, denn so siehst du ob ein io Prozess noch am laufen ist oder ob er wegen eines Fehlers abgebrochen hat, bzw. die einzelnen Migrationsschritte runtertattern.

Bei der Migration gibt es immer wieder Prozesse, die etwas länger dauern können, da kann man leicht nervös werden.
In deinem Fall gehe ich davon aus, das die Prozesse, wo es dann hing, eventuell länger dauerten als die eigentliche Scriptlaufzeit erlaubte und das diese dadurch vorzeitig beendet wurden.

Die Datenbank arbeitet an dem betreffendem Query aber fast immer weiter, was man dann eigentlich prüfen sollte bevor man da das Update unbedarft neu startet.

Zur Veranschaulichung hier mal ein Screenshot (ist jetzt nicht von einem Update aber vergleichbar), was ich mit offener console meine
(man sieht dann wenn es einen Abbruch des Prozesses gab und kann in dem Antwort tab auch sehen was los war, sofern man das error_reporting aktiv hat)

 

[MrS]

Aber wie lange dauert der Vorgang? Ich habe schon ändere Webanwendungen mit Datenbank aktualisiert, da dauert es nie so lange, ohne dass etwas passiert. Nextcloud ist z.b. so ein Kandidat. Ich habe hier eine laufen mit ca 50 Usern und über 1 TB an Daten. Da dauert das Update ein paar Minuten.

Vielleicht wäre es sinnvoll den Fortschritt zu visualisieren

 

[css-umsetzung]

Du kannst bei einem MySQL Prozess nicht sagen wie weit er fortgeschritten ist wenn du einen Query auslöst (wäre mir jedenfalls neu)
Es gibt einige Query die je nach Inhalt sehr lange dauern können, insbesondere wenn es beim Umstieg von 4 auf 5 um die Preise, Kundenattribute oder Zahlungen geht.

beim Umstieg von 5.2 auf 5.3 wird die collation geändert, auch das kann seine Zeit dauern oder eben andere Ursachen haben das es etwas länger dauert oder abbricht.

 

[MrS]

Du kannst bei einem MySQL Prozess nicht sagen wie weit er fortgeschritten ist wenn du einen Query auslöst (wäre mir jedenfalls neu)
Es gibt einige Query die je nach Inhalt sehr lange dauern können, insbesondere wenn es beim Umstieg von 4 auf 5 um die Preise, Kundenattribute oder Zahlungen geht.

beim Umstieg von 5.2 auf 5.3 wird die collation geändert, auch das kann seine Zeit dauern oder eben andere Ursachen haben das es etwas länger dauert oder abbricht.

Ich hab die collation dann ja manuell auf der DB mit phpmysdmin geändert. Das war in wenigen Sekunden erledigt. Also kann doch der Prozess auch nicht viel länger dauern, wenn es über den Shop gemacht wird. Gleiche Userdaten und localhost. Wäre schon sehr komisch, wenn das so ist 😉

 

[MrS]

Bei der Nextcloud ist es auch einmal passiert, dass ein Update nicht durchgelaufen ist. Da konnte ich es einfach über das cli beenden. Gibt es diese Möglichkeit beim Shop auch? Wäre vielleicht eine gute Alternative, wenn es über die Webanwendung Probleme gibt

 

[css-umsetzung]

Beim JTL werden die einzelnen Updateschritte, die erfolgreich waren gespeichert, so dass der Shop, da wo er aufgehört hat weitermacht, aber man muss das halt über die console beobachten, da die Rückmeldung per Ajax kommt und wenn der Shop wegen eines Fehlers oder aus anderen Gründen abgebrochen hat, dann gibt es diese Meldung eben nicht.

Man sollte aber auch, wie ich es schon schrieb, die Prozesse der Datenbank im Blick behalten wenn es eben einen Fehler gab.

Es hat schon Gründe, warum, ich nicht einfach mal schnell ein Shop Update mache wenn sich die Versionsnummer grundlegend ändert..