搬到新服务器后,我每天都会收到一次MySQL Crash [1]问题,这会来到我的电子邮件中,更烦人,更不用说潜在的影响了。有任何暗示如何调试这个问题?

显然崩溃发生了 $schedule->save() 所以我试图尝试一下...捕获,但这无济于事

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}

超时设置:

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)
有帮助吗?

解决方案

正如其他人所说的那样,这很可能是由长期运行的脚本触发的。任何不使用数据库的脚本都需要很长时间运行,可能会超时。

我以前发生了这种情况。我们有一个连接到远程服务器,下载几百个XML文件的脚本,解析并将其转换为.csv文件,以通过内置的Magento Importexport模块导入。我们有一个自定义日志记录模块,它使我们能够跟踪例程发生的情况。班级要做的第一件事是在此日志表中添加一行以说例程开始。然后需要5-10分钟才能获取远程XML文件。下载文件后,它试图编写另一个日志条目,以说它已经完成。由于MySQL连接自第一个日志事件以来一直打开,并且此后一直没有使用,因此MySQL已关闭该连接,因为它在超时期内没有收到的查询更长。

其他提示

在你的 /etc/mysql/my.cnf 尝试增加价值 max_allowed_packet

例如。

max_allowed_packet = 256M

然后重新启动mysql。

如果您问我,将MySQL连接保持几个小时不是一个好主意。因此,替代方法是检查连接仍然存在,如果否,请打开一个新的连接。

许可以下: CC-BY-SA归因
scroll top