Cron plante MySQL

Après avoir déménagé sur un nouveau serveur, je reçois le problème de crash MySQL [1] une fois par jour, qui arrive dans mon e-mail et ennuyeux sans parler de son impact potentiel. Des conseils sur la façon de déboguer ce problème?

De toute évidence, le crash se produit $schedule->save(), j'ai donc essayé de l'envelopper avec un essai ... attraper, mais cela n'a pas aidé

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}

Paramètres de délai:

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)

Comme d'autres l'ont dit, il est probablement déclenché par un script de longue durée. Tout script dont l'exécution est longue sans utiliser la base de données peut potentiellement expirer.

Je l'ai déjà fait auparavant. Nous avons un script qui se connecte à un serveur distant, télécharge quelques centaines de fichiers xml, les analyse et les convertit en un fichier .csv pour importation via le module Magento ImportExport intégré. Nous avons un module de journalisation personnalisé, qui nous permet de suivre ce qui s'est passé avec nos routines. La toute première chose que fait la classe est d'ajouter une ligne à cette table de journal pour dire que la routine a commencé. Il faut ensuite 5 à 10 minutes pour récupérer les fichiers xml distants. Après avoir téléchargé les fichiers, il tente d'écrire une autre entrée de journal pour dire qu'il est terminé. Étant donné que la connexion mysql est ouverte depuis le premier événement de journalisation et n'a pas été utilisée depuis, mysql a fermé la connexion car elle n'a reçu aucune requête pendant plus de la période d'expiration.

Dans votre /etc/mysql/my.cnftentative, augmentez la valeur demax_allowed_packet

Par exemple.

max_allowed_packet = 256M

Redémarrez ensuite MySQL.

Si vous me demandez, ce n'est pas une bonne idée de garder une connexion mysql ouverte pendant des heures. Donc, l'alternative est, pour vérifier si la connexion existe toujours, sinon, ouvrez-en une nouvelle.