Cron accidentes de MySQL

Question

Después de trasladarse a un nuevo servidor que estoy recibiendo el accidente MySQL [1] problema de una vez al día, lo que viene a mi correo electrónico y molesto por no hablar de impacto potencial. ¿Alguna pista sobre cómo depurar este problema?

Obviamente accidente ocurre en $schedule->save() así que traté de envolverlo con un try ... catch, pero eso no ayuda

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}

ajustes 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)

Answer 1

Como otros han dicho que es probable que desencadena por una secuencia de comandos de larga duración. Cualquier script que toma mucho tiempo para correr sin necesidad de utilizar la base de datos puede potencialmente tiempo de espera.

He tenido que esto ocurra antes. Tenemos un guión que se conecta a un servidor remoto, descargas de unos pocos cientos de archivos XML, lo analiza y convierte en un archivo CSV para su importación a través de la incorporada en el módulo de Magento ImportExport. Tenemos un módulo de registro personalizado, lo que nos permite rastrear lo que pasó con nuestras rutinas. Lo primero que hace la clase, es añadir una fila a esta tabla de registro decir comenzó rutina. A continuación, toma 5-10 minutos para buscar los archivos XML remoto. Después de descargar los archivos que intenta escribir otra entrada de registro para decir que esté terminado. Dado que la conexión MySQL ha estado abierto 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 período de tiempo de espera.

Answer 2

En su /etc/mysql/my.cnf intente aumentar el valor para max_allowed_packet

Ej.

max_allowed_packet = 256M

A continuación, MySQL reinicio.

Answer 3

Si me preguntas, no es una buena idea para mantener una conexión abierta MySQL durante horas. Por lo que la alternativa es, para comprobar, wether todavía existe la conexión, si no, abrir una nueva.