Cron crash MySQL

Question

Dopo essersi trasferito in un nuovo server sto ottenendo l'arresto di MySQL [1] problema una volta al giorno, che è venuta alla mia email e fastidioso per non parlare di potenziale impatto. Eventuali suggerimenti su come eseguire il debug questo problema?

Ovviamente incidente accade su $schedule->save() così ho provato a avvolgerlo con un try ... catch, ma questo non ha aiutato

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}

Impostazioni di attesa:

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

Come altri hanno detto che è probabile che innescato da uno script di lunga esecuzione. Qualsiasi script che richiede molto tempo per eseguire senza utilizzare il database può potenzialmente timeout.

Ho avuto questo accadere prima. Abbiamo uno script che si connette a un server remoto, download a poche centinaia di file XML, analizza e li converte in un file .csv per l'importazione tramite il costruito nel modulo di Magento ImportExport. Abbiamo un modulo di registrazione personalizzato, che ci permette di monitorare cosa è successo con la nostra routine. La prima cosa la classe fa, è aggiungere una riga a questa tabella di registro per dire di routine iniziato. Ci vogliono poi 5-10 minuti per andare a prendere i file XML remoti. Dopo aver scaricato i file che tenta di scrivere un'altra voce di registro per dire che è finito. Poiché la connessione mysql è stato aperto dal primo evento di registro e non è stato utilizzato fin, mysql ha chiuso la connessione in quanto non ha ricevuto alcuna richiesta per più lungo del periodo di timeout.

Answer 2

Nel vostro /etc/mysql/my.cnf provare ad aumentare il valore per max_allowed_packet

Eg.

max_allowed_packet = 256M

Poi MySQL riavvio.

Answer 3

Se mi chiedete, non è una buona idea per mantenere una connessione mysql aperta per ore. Quindi l'alternativa è, per controllare, montone castrato il collegamento esiste ancora, se no, aprirne uno nuovo.