Cron stürzt MySQL ab

Nach dem Wechsel auf einen neuen Server erhalte ich einmal am Tag das Problem mit dem MySQL-Absturz [1], das in meine E-Mail eingeht und ärgerlich ist, ganz zu schweigen von möglichen Auswirkungen. Gibt es Hinweise zum Debuggen dieses Problems?

Offensichtlich passiert ein Absturz, $schedule->save()also habe ich versucht, ihn mit einem Versuch zu verpacken ... zu fangen, aber das hat nicht geholfen

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Trace:
#0 /var/www/vhosts/site/store/lib/Zend/Db/Adapter/Pdo/Abstract.php(305): PDO->beginTransaction()
#1 /var/www/vhosts/site/store/lib/Zend/Db/Adapter/Abstract.php(495): Zend_Db_Adapter_Pdo_Abstract->_beginTransaction()
#2 /var/www/vhosts/site/store/lib/Varien/Db/Adapter/Pdo/Mysql.php(219): Zend_Db_Adapter_Abstract->beginTransaction()
#3 /var/www/vhosts/site/store/app/code/core/Mage/Core/Model/Resource/Abstract.php(76): Varien_Db_Adapter_Pdo_Mysql->beginTransaction()
#4 /var/www/vhosts/site/store/app/code/core/Mage/Core/Model/Abstract.php(313): Mage_Core_Model_Resource_Abstract->beginTransaction()
#5 /var/www/vhosts/site/store/app/code/core/Mage/Cron/Model/Observer.php(125): Mage_Core_Model_Abstract->save()
#6 /var/www/vhosts/site/store/app/code/core/Mage/Core/Model/App.php(1338): Mage_Cron_Model_Observer->dispatch(Object(Varien_Event_Observer))
#7 /var/www/vhosts/site/store/app/code/core/Mage/Core/Model/App.php(1317): Mage_Core_Model_App->_callObserverMethod(Object(Mage_Cron_Model_Observer), 'dispatch', Object(Varien_Event_Observer))
#8 /var/www/vhosts/site/store/app/Mage.php(447): Mage_Core_Model_App->dispatchEvent('default', Array)
#9 /var/www/vhosts/site/store/cron.php(46): Mage::dispatchEvent('default')
#10
{main}

Timeout-Einstellungen:

mysql> show global variables like '%timeout%';
+----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| connect_timeout            | 10       |
| delayed_insert_timeout     | 300      |
| innodb_lock_wait_timeout   | 50       |
| innodb_rollback_on_timeout | OFF      |
| interactive_timeout        | 30       |
| lock_wait_timeout          | 31536000 |
| net_read_timeout           | 30       |
| net_write_timeout          | 60       |
| slave_net_timeout          | 3600     |
| wait_timeout               | 3600     |
+----------------------------+----------+
10 rows in set (0.00 sec)

Wie andere gesagt haben, wird es wahrscheinlich durch ein lang laufendes Skript ausgelöst. Jedes Skript, dessen Ausführung ohne Verwendung der Datenbank lange dauert, kann möglicherweise eine Zeitüberschreitung verursachen.

Ich habe das schon einmal erlebt. Wir haben ein Skript, das eine Verbindung zu einem Remote-Server herstellt, einige hundert XML-Dateien herunterlädt, analysiert und in eine CSV-Datei konvertiert, um sie über das integrierte Magento ImportExport-Modul zu importieren. Wir haben ein benutzerdefiniertes Protokollierungsmodul, mit dem wir verfolgen können, was mit unseren Routinen passiert ist. Das allererste, was die Klasse tut, ist, dieser Protokolltabelle eine Zeile hinzuzufügen, um zu sagen, dass die Routine gestartet wurde. Das Abrufen der Remote-XML-Dateien dauert dann 5-10 Minuten. Nach dem Herunterladen der Dateien wird versucht, einen weiteren Protokolleintrag zu schreiben, um anzuzeigen, dass der Vorgang abgeschlossen ist. Da die MySQL-Verbindung seit dem ersten Protokollereignis geöffnet war und seitdem nicht mehr verwendet wurde, hat MySQL die Verbindung geschlossen, da es länger als die Zeitüberschreitung keine Abfrage erhalten hat.

In Ihrem /etc/mysql/my.cnfVersuch, den Wert für zu erhöhenmax_allowed_packet

Z.B.

max_allowed_packet = 256M

Starten Sie dann MySQL neu.

Wenn Sie mich fragen, ist es keine gute Idee, eine MySQL-Verbindung stundenlang offen zu halten. Die Alternative besteht also darin, zu überprüfen, ob die Verbindung noch besteht. Wenn nein, öffnen Sie eine neue.