MySQL サーバーは、特定のタイプのクエリで常にロックアップして応答を停止し、最終的に (数分間応答しないと) エラー「 MySQL server has gone away 」であきらめ、次の一連のクエリで再びハングアップするようです。そしてまた。dbAサーバーは、マスターから主に INSERT ステートメントに 1 秒あたり約 5 ～ 10 行でレプリケートするスレーブとして設定されます。PHP ベースのアプリケーションがサーバー上で実行されており、5 ～ 10 秒ごとに新しく複製されたデータを読み取り、それを処理して (INSERT ON DUPLICATE KEY UPDATE) 結果を別のデータベースに保存します。dbB. すべてのテーブルは MyISAM エンジンを使用します。Web アプリケーションは、後処理されたデータをユーザーに表示します。基本的には、関連する処理手順は、1 秒あたりの解像度の時系列データを 1 分あたり、1 時間あたり、および 1 日あたりの解像度に圧縮することです。
MySQL がロックしたときに SHOW PROCESSLIST コマンドを実行すると、次のクエリが表示されます。
N User Time Status SQL query
1 system user XX update INSERT INTO `dbA`.`tableA` (...) VALUES (...)
2 ???? XX Waiting for query cache lock INSERT INTO `dbB`.`tableB` (...) VALUES (...) ON DUPLICATE KEY UPDATE ...
3 ???? XX Writing to net SELECT ... FROM `dbA`.`tableA` WHERE ... ORDER BY ...
「時間」列は、ある種のクエリ待機タイムアウトに達するまで同期的に刻み続け、その後「MySQL サーバーが消えました」というエラーが発生します。5 ～ 10 秒後に新しいデータを再び処理する時間になると、同じロックアップが発生します。クエリ #1 はレプリケーション プロセスです。クエリ #2 は、後処理されたデータの更新です。クエリ #3 は、新しくレプリケートされたデータを処理のためにストリーミング (バッファリングなし) しています。おそらくそれが最初にタイムアウトしたため、最終的に「 MySQLサーバーが消えました」というエラーを生成するのはクエリ＃3です。
ある種のデッドロックのように見えますが、その理由はわかりません。あるデータベースで SELECT と INSERT を同時に実行すると、別のデータベースでの INSERT ON DUPLICATE KEY UPDATE によるクエリ キャッシュの更新でデッド ロックが発生するようです。レプリケーションまたはクエリ キャッシュをオフにすると、ロックアップは発生しません。プラットフォーム: Debian 7、MySQL 5.5.31、PHP 5.4.4 - すべての標準パッケージ。ほぼ同じアプリケーションが現在Debian 6、MySQL 5.1.66、PHP 5.3.3で正常に動作していることは注目に値するかもしれませんが、後処理されたデータが INSERT ON ではなく個別の INSERT および UPDATE クエリを使用して保存されるという点のみが異なります。重複キーの更新。
MySQL 構成 (Debian 6 および 7 マシンの両方):
key_buffer_size = 2G
max_allowed_packet = 16M
thread_cache_size = 64
max_connections = 200
query_cache_limit = 2M
query_cache_size = 1G
このロックアップが発生する理由についてのヒントをいただければ幸いです。