Cron si arresta in modo anomalo su MySQL

Dopo essermi trasferito su un nuovo server ricevo il problema dell'arresto anomalo di MySQL [1] una volta al giorno, che arriva sulla mia e-mail e fastidioso per non parlare del potenziale impatto. Qualche suggerimento su come eseguire il debug di questo problema?

Ovviamente si verifica un incidente, $schedule->save()quindi ho cercato di avvolgerlo con un tentativo ... cattura 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 timeout:

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)

database error

— Zifius
fonte

Questo è PHP che perde la connessione con MySQL. Conoscere magento è probabilmente perché il file cron.php richiede ore per essere eseguito. Prova a guardare le impostazioni di timeout di MySQL ...

— Matt Humphrey,

Potresti controllare mysql LOG! molto probabilmente mysql si arresta in modo anomalo e si riavvia quando si tenta di interrogare quella tabella

— Meabed,

Il problema @MattHumphrey sta accadendo solo una volta al giorno mentre cron.php viene eseguito ogni 15 minuti, i timeout sono già piuttosto elevati

— Zifius,

Non penso che questa sia una domanda specifica su Magento. Quello che stai descrivendo è un timeout della connessione su un server MySQL, che normalmente viene ripristinato impostando un'opzione di riconnessione sulla connessione e eseguendo il ping del server prima dell'uso. Guarderei la tua configurazione MySQL ( my.cnf) per vedere qual è il timeout e aumentarlo. Vedi stackoverflow.com/questions/4284194/… per i dettagli.

— Karlson,

@Zifius Quali sono le impostazioni di timeout?

— Karlson,

Risposte:

Come altri hanno già detto, è probabilmente innescato da una sceneggiatura di lunga durata. Qualsiasi script che richiede molto tempo per essere eseguito senza utilizzare il database può potenzialmente andare in timeout.

L'ho già successo prima. Abbiamo uno script che si collega a un server remoto, scarica alcune centinaia di file xml, analizza e li converte in un file .csv per l'importazione tramite il modulo Magento ImportExport incorporato. Abbiamo un modulo di registrazione personalizzato, che ci consente di tenere traccia di ciò che è accaduto con le nostre routine. La prima cosa che fa la classe è aggiungere una riga a questa tabella di registro per dire che la routine è iniziata. Sono quindi necessari 5-10 minuti per recuperare i file XML remoti. Dopo aver scaricato i file tenta di scrivere un'altra voce di registro per dire che è finita. Poiché la connessione mysql è stata aperta dal primo evento di registro e non è stata utilizzata da allora, mysql ha chiuso la connessione in quanto non ha ricevuto query per un periodo di tempo superiore al periodo di timeout.

— Peter O'Callaghan
fonte

Sì, sembra essere il colpevole tenendo conto del fatto che i lavori cron vengono eseguiti al di sopra della riga che salva la voce. Aggiunti altri log per scoprire quale lavoro è quello

— Zifius,

Nel tuo /etc/mysql/my.cnftentativo di aumentare il valore permax_allowed_packet

Per esempio.

max_allowed_packet = 256M

Quindi riavviare MySQL.

— Ben Lessani - Sonassi
fonte

In questo momento è a 64M, proverà ad aumentare. Vedo anche molto "Troppo tardi per il programma". eccezioni, deve essere un lavoro pesante che dura troppo a lungo

— Zifius,

Crawler FPC disabilitato come da tua raccomandazione in un'altra domanda, vediamo come va

— Zifius

Questa è la causa più frequente del problema quando si verifica questo errore.

— davidalger,

Se me lo chiedi, non è una buona idea tenere aperta una connessione mysql per ore. Quindi l'alternativa è, per verificare, se la connessione esiste ancora, se no, aprirne una nuova.

— Fabian Blechschmidt
fonte

È un codice di base, ma sì, hai ragione :) Devo solo rintracciare il lavoro che funziona così a lungo ora

— Zifius

forse c'è un osservatore che puoi usare per controllare, se esiste la connessione?

— Fabian Blechschmidt,

Penso di aver solo bisogno di trovare e riparare quel lavoro :)

— Zifius,

A seconda di quante visualizzazioni, categorie e prodotti hai, può essere un indicizzatore e questo potrebbe richiedere del tempo. Ma sì, "basta aggiustare il lavoro" e il problema è sparito: D

— Fabian Blechschmidt,