SELECT RELEASE_LOCKが原因で「MySQLがなくなった」
実行時間の長いプロセス（90分以上）の間、コードはSELECT RELEASE_LOCK('..');を呼び出します。ただし、これを行うと、常に "Mysql has gone away"エラーが発生します。
RELEASE_LOCKの戻り値を見たことはありません。クエリは実行されませんでした。結果が見つかる前に接続が切断されました。
これまでにこの問題に遭遇したことはありません。 Magento 1.12から1.13にアップグレードした後です
さまざまなタイムアウトを増やすなど、さまざまなことを試みましたが、役に立ちませんでした。良いデバッグ戦略またはこの問題を引き起こしている可能性があるものは何でしょうか？
これについての最も可能性の高い説明は、ネットワークハードウェアの中間部分がアイドル状態を解除または「忘れている」ことですTCP接続、 wait_timeout システム変数が設定されていないと想定）低すぎる。
ステートフルファイアウォールは、現在のすべての「フロー」の内部データ構造（送信元/宛先アドレス/ポートクワッド）を維持します。フローに長時間トラフィックがない場合、フローのレコードはファイアウォールのメモリから削除されるだけです。到着する次のTCPパケットは確立されたフローと一致せず、SYNフラグが設定されていないため、新しい接続ではなく、ファイアウォールがそれを考慮します無効であり、ドロップするか、宛先からRSTパケットをスプーフします。
たとえば、anyクエリSELECT NOW();を使用すると、同じエラーが発生する可能性が高く、接続後はおそらく同じ結果が返されます完全に長い間アイドル状態でした。クエリを実行しても、TCPレイヤーで接続が「アイドル」になるのを防ぐことはできません。
その間、接続はプロセスリストから消えない可能性があります。これは、完全にアイドル状態であるため、サーバーは何も送信せず、ネットワーク上のある時点で無効であることを認識しなかったためですTCP接続。
これは、私の経験ではほんの一例ですが、Amazon EC2内で発生します。
回避策は、接続の少なくとも一方の端でオペレーティングシステム自体のTCPキープアライブを有効にすることです。これにより、TCPトラフィックが接続にペイロードがない場合でも、アイドル時間中のホストこれらを有効にすると、この問題が解決されます。
Linux： http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html
Windows： https://technet.Microsoft.com/en-us/library/cc957549.aspx
好奇心が強い場合は、試行錯誤によって、アイドル接続が使用できなくなるまでの期間を検出できるようにする必要があります。たとえば、14分間アイドル状態のままにした接続は問題ないかもしれませんが、アイドル状態のままの接続は16分間は常に停止します。これは、ファイアウォールに15分のフロー有効期限タイマーがあることを示しています。