質問

新しいサーバーに移動した後、私は1日1回MySQLクラッシュ[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ファイルをダウンロードし、解析し、それらを組み込まれたMagento ImporteXportモジュールを介してインポート用の.CSVファイルに変換するスクリプトがあります。カスタムロギングモジュールがあります。これにより、ルーチンで何が起こったのかを追跡できます。クラスが最初に行うことは、このログテーブルに行を追加して、ルーチンが開始されたと言うことです。その後、リモートXMLファイルを取得するには5〜10分かかります。ファイルをダウンロードした後、別のログエントリを作成して、終了したと言っています。 MySQL接続は最初のログイベント以来開いており、それ以来使用されていないため、MySQLはタイムアウト期間より長くクエリを受け取っていないため、接続を閉じています。

他のヒント

あなたの中で /etc/mysql/my.cnf の値を増やしてみてください max_allowed_packet

例えば。

max_allowed_packet = 256M

次に、mysqlを再起動します。

あなたが私に尋ねると、MySQL接続を何時間も開いたままにすることは良い考えではありません。したがって、代替案は、チェックするために、接続がまだ存在する場合、いいえ、新しいものを開くことです。

ライセンス: CC-BY-SA帰属
所属していません magento.stackexchange
scroll top