Cron bloquea MySQL

Después de mudarme a un nuevo servidor, recibo el problema de bloqueo de MySQL [1] una vez al día, que llega a mi correo electrónico y es molesto sin mencionar el impacto potencial. ¿Alguna pista sobre cómo depurar este problema?

Obviamente, el bloqueo ocurre, $schedule->save()así que intenté envolverlo con un intento ... atrapar pero eso no ayudó

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}

Configuración de tiempo de espera:

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)

Como otros han dicho, es probable que sea provocado por un script de larga ejecución. Cualquier script que demore mucho tiempo en ejecutarse sin usar la base de datos puede potencialmente agotar el tiempo de espera.

Me ha pasado esto antes. Tenemos un script que se conecta a un servidor remoto, descarga algunos cientos de archivos xml, los analiza y los convierte en un archivo .csv para importarlos a través del módulo Magento ImportExport integrado. Tenemos un módulo de registro personalizado, que nos permite rastrear lo que sucedió con nuestras rutinas. Lo primero que hace la clase es agregar una fila a esta tabla de registro para decir que la rutina comenzó. Luego toma de 5 a 10 minutos recuperar los archivos xml remotos. Después de descargar los archivos, intenta escribir otra entrada de registro para decir que ha terminado. Dado que la conexión mysql ha estado abierta desde el primer evento de registro y no se ha utilizado desde entonces, mysql ha cerrado la conexión ya que no ha recibido ninguna consulta durante más tiempo que el tiempo de espera.

En su /etc/mysql/my.cnfintento de aumentar el valor demax_allowed_packet

P.ej.

max_allowed_packet = 256M

Luego reinicie MySQL.

Si me preguntas, no es una buena idea mantener una conexión mysql abierta durante horas. Entonces, la alternativa es, para verificar, si la conexión aún existe, si no, abra una nueva.