ich wollte meinen Shop von 6.4 auf 6.5 updaten und bin dabei auf ein paar Probleme gestoßen - Die meisten konnte ich beheben, nur ein Problem habe ich weiterhin.
Wenn ich versuche Varianten zu erzeugen, bricht es schnell ab und in der Browser Konsole finde ich dann folgenden Fehler:
„1213 Deadlock found when trying to get lock; try restarting transaction“
Was mich daran am meisten verwirrt, ist, dass dieses Problem auch bei einer neuen Shopware 6.5 Instalation auftaucht. Habe es mit MySQL und auch MariaDB probiert - bei beiden das gleiche Problem. Habe bereits versucht, LOCK_DSN (Da ich davon ausgehe, dass dies damit zu tun hat) auf der Standardeinstellung (Flock) zu lassen, es auf Redis gestellt, es auf PostgreSQL gestellt - mit allen das gleiche Problem.
Hat irgendwer noch eine Idee, woran dies liegen kann? Alles andere funktioniert einwandfrei, und dies ist aktuell das einzige Problem, welches mit davon abhält, auf 6.5 zu updaten.
ich glaube, dass es sich um seltsames Verhalten beim Hosting Provider Deiner Wahl handeln könnte: Irgendwas bei der DB-Konfiguration kann doch dort nicht passen. Bei wem bist Du denn?
Und an welcher Stelle genau beschreibt der von Dir verlinkte Beitrag das Problem was @neneya hier versucht zu lösen? Ganz ehrlich: Ich verstehe nicht, warum das hier dazwischen geklebt wird.
ich bin der Hoster. Also, nicht komplett selbst gehostet, aber über Hetzner einen Server gemietet.
Ich arbeite im Bereich SysAdmin/DevOps, daher liegt es mir eher, meine Server selbst zu verwalten. Das macht das Lösen vieler Probleme auch einfacher, insofern es nicht ein eher trickiges Problem ist wie dies hier.
Für die Datenbanken nutze ich Docker - sowohl bei MariaDB als auch MySQL.
Ich habe es bereits mit MariaDB und MySQL probiert. Mit 1:1 der selben Konfiguration funktioniert alles einwandfrei unter Shopware 6.4. Sowohl unter der „Standard“ Konfiguration, mit denen die Datenbanken in den Docker containern kommen, als auch mit ein paar extra Einstellungen - selbes Ergebnis.
Die Shopware 6.5 Instanzen bei denen das Problem auftritt sind auch frisch installierte Instanzen - Da mein Shop recht neu ist habe ich es mit einem Upgrade von 6.4 auf 6.5 erst garnicht versucht, sondern hatte geplant 6.5 neu einzurichten und die selben Daten manuell einzuspielen. Daher ist mir das Problem beim Varianten generieren auch recht schnell aufgefallen.
Dies macht es allerdings nur komplizierter, da die Möglichkeit, dass es am Upgrade liegt bzw. an irgendwelchen alten Konfigurationen unmöglich.
Ich habe auch ein bisschen nachgelesen, und Deadlocks sind bei Datenbanken anscheinend „recht normal“ und einfach etwas, welches im Code beachtet werden sollte?
Was mir aufgefallen ist, ist dass unter Shopware 6.5 die Variantengeneration immens schneller ist als unter Shopware 6.4 - was bei mir die Vermutung bringt, dass 6.5 eventuell die Varianten tatsächlich „zu schnell“ generiert und es deshalb in der Datenbank zu Deadlocks kommt, da Transaktionen an InnoDB gesendet werden, während vorherige Transaktionen noch laufen. Ich habe hierfür zwar keinen Nachweis - Wäre aber mein Hauptverdacht persönlich.
Genau. Deadlocks sind nicht selten und können immer wieder aufkreuzen. Eklig wird’s erst dann, wenn es wirklich sehr viele gibt oder wenn man merkt, dass Applikationsfunktionalität nicht mehr ausgeführt werden kann.
Im nächsten Schritt müsste man sich wohl genau anschauen, bei Ausführung welcher Query Deadlocks generiert werden. Das ganze ist insofern spannend, weil ja eigentlich noch Doctrine dazwischen ist.
Ich werde mal schauen, dass ich aus den SQL logs die Query herausfinde, scheint nach kurzer Recherche recht einfach zu sein, Deadlocks zu loggen. Ich melde mich nochmal, sobald ich Info über die Queries habe.
Was mir auch aufgefallen ist, was ich am Anfang ignoriert habe, allerdings nach mehreren neuen 6.5 Installationen recht konsistent ist:
Beim ersten Versuch, Varianten zu generieren, läuft es meist bis in die hunderte, ab und zu sogar bis 1000+ Varianten generiert, bevor es crasht - wenn ich dann allerdings die Variantengeneration einfach wieder starte, sobald ~1000 Varianten existieren, erscheint der Abbruch durch Deadlock konsistent nach <100 Varianten generiert.
Läuft bei dir evtl. die Indexierung asynchron im Hintergrund (durch bin/console messenger:consume)? Bei der Indexierung wird ständig die „updated_at“ Spalte Produkten geschrieben. Dabei kann es schnell zu Deadlocks kommen. Gerade wenn man viele größere Chunks übermittelt bzw. die Transaktionen lange offen sind.