Wir haben seit längerem das Problem, dass beim Speichern von Artikeländerung in OXID (Version: PE v6.1.4) regelmäßig MySQL Deadlocks auftreten:
2020-01-28T11:02:04.398678Z 47312408 [Note] InnoDB: Transactions deadlock detected, dumping detailed information.
In OXID stellt sich das Problem so dar, dass beim Speichern, im iFrame mit den Artikelinformationen ein Maintenance Mode Hinweis auftaucht und kurz danach auf die Homepage weitergeleitet wird, soweit OXID Standardverhalten.
Das Phänomen tritt auch beim Import mit dem D³ Artikelimporter auf.
Wir untersuchen das Problem schon seit mehreren Monaten und konnten bisher keine Problemlösung finden.
Das Problem ist auch, dass wir den Fehler schlecht reproduzieren können, weil er regelmäßig auftritt, aber in unregelmäßigen Abständen. Und er tritt nur auf, wenn Daten verändert werden, d.h. wenn ich z.B. die Artikelbeschreibung anpasse, dann speichere, dann tritt der Fehler evtl. auf. Wenn er auftritt und ich dann nur den iFrame neulade, dann wird u.U. der Speicherungsprozess sofort abgeschlossen oder ich muss den Vorgang mehrere Male wiederholen. Sobald der iFrame aber wieder erfolgreich geladen hat und ich dann wieder Änderungen vornehme, tritt der Fehler nur u.U. wieder auf. – Zu über 95% tritt der Fehler nicht auf.
Wir hatten das Problem auch schon mit OXID PE 4 (vor 10/2018), allerdings nur sehr selten, so dass wie das Problem nicht weiter untersucht haben und es eher auf Lastspitzen geschoben haben.
Was noch ein Problem ist, dass wir in den Standard Logs Apache, PHP, OXID, MySQL etc. und in Tideways keine Fehler feststellen bzw. dokumentieren können, was sehr ungewöhnlich ist.
Z.B. in Tideways wird zwar ein ERROR 500 bzw. der Deadlock dokumentiert, allerdings keine weitergehenden Informationen.
Die Information zum Deadlock haben wir in Kooperation mit PROFIHOST in einem Slow-Query Log gesammelt (hier der komplette Deadlock: https://www.dropbox.com/s/u23hvwdxtxjolj5/46869_deadlock.log?dl=0).
Eine weitere Erkenntnis, die wir sammeln konnten, ist, dass der Fehler bisher nur auf unserem Live-System festgestellt werden konnte, auf unserem Staging- bzw. Entwicklungssystem (alls bei PROFIHOST; allerdings unterschiedliche Culster) noch nicht reproduziert werden konnten.
Größter Unterschied zwischen den Systemen ist, dass das Live-System auf getrennten Webserver und Datenbank-Server besteht und Cloudflare vorgelagert hat. Des Weiteren haben weder das Staging-, noch das Entwicklungssystem vereinbaren Traffic.
Vielleicht hilft auch noch der Hinweis, dass der Fehler auch beim Speichern von Artikelbeschreibungen auftritt, also auch wenn die oxartextend betroffen ist und nicht nur die oxarticles.
Es sind auch völlig unterschiedlichen Daten, bei denen der Deadlock auftritt: Titel, Beschreibung, Bilder, Varianten und Artikel kopieren
Wir haben auch schon den Ansatz verfolgt, dass das Problem im Zusammenhang mit Cronjobs zusammenhängt, schließen das aber mittlerweile fast aus, weil die meisten Automatisierungen nur einmalige Änderungen durchführen und nicht laufen und i.d.R. nachts.
Einzig Pixi verarbeitet die Artikel dauerhaft, allerdings im Nachgang, wenn sich der Timestamp ändert.
Hat jemand schon einmal ein vergleichbares Phänomen gehabt oder eine Idee, wie wir den Fehler besser eingrenzen können?