Cron stürzt MySQL ab

Question

Nachdem ich auf einen neuen Server gezogen bin, bekomme ich einmal am Tag das Problem des MySQL -Absturzes [1]. Irgendwelche Hinweise darauf, wie man dieses Problem debuggen?

Offensichtlich kommt der Absturz auf $schedule->save() Also habe ich versucht, es mit einem Versuch zu wickeln ... Fang, aber das half nicht

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}

Zeitüberschreitungseinstellungen:

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)

Answer 1

Wie andere gesagt haben, wird es wahrscheinlich durch ein langjähriges Skript ausgelöst. Jedes Skript, dem es lange dauert, ohne die Datenbank zu verwenden, kann potenziell Zeitüberschreitungen.

Ich habe das schon einmal geschehen. Wir haben ein Skript, das eine Verbindung zu einem Remote -Server herstellt, einige hundert XML -Dateien heruntergeladen, analysiert und in eine .csv -Datei für den Import über das integrierte Magento Importexport -Modul in eine .csv -Datei konvertiert. Wir haben ein benutzerdefiniertes Protokollierungsmodul, mit dem wir nachverfolgen 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 Routine gestartet wurde. Es dauert dann 5-10 Minuten, um die Remote-XML-Dateien abzurufen. Nach dem Herunterladen der Dateien versucht es, einen weiteren Protokolleintrag zu schreiben, um zu sagen, dass es fertig ist. Seitdem die MySQL -Verbindung seit dem ersten Protokollereignis geöffnet ist und seitdem nicht mehr verwendet wurde, hat MySQL die Verbindung geschlossen, da sie länger als die Zeitlimitzeit nicht abfragt hat.

Answer 2

In deiner /etc/mysql/my.cnf Versuchen Sie, den Wert für den Wert zu erhöhen max_allowed_packet

Z.B.

max_allowed_packet = 256M

Dann starten Sie MySQL neu.

Answer 3

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 immer noch vorhanden ist, wenn nein eine neue.