2 週間前に、ウェブサーバーでホストされている postgres インスタンスから Amazon RDS でホストされている mysql インスタンスにデータベースを移行しました。
移行後、リクエストの約 0.5% で「クエリ中に接続が失われました」というエラーが発生し始め、Web リクエストが失敗しました。移行前 (Postgres を使用していたとき)、この問題はこれまで見たことがありませんでした。
「クエリ中に接続が失われた」というエラーに関する多くのドキュメントが、mysql やオンラインの他のコミュニティから提供されています。この問題は、開発またはステージングでは再現できず、本番環境でのみ再現できます。この問題は本番環境では比較的めったに発生しませんが、1 つのページ (管理ダッシュボード) で多数のクエリを実行する ActiveAdmin のかなり複雑なページにアクセスすると、より頻繁に発生するようです。
これまでに試したもののリストは次のとおりです。
1) 'wait_timeout' 変数 - 接続プール接続が 8 時間後に終了することとは関係がないため、これは当てはまらないようです。データベースと Rails アプリを再起動し、アクティブな管理ダッシュボード ページにアクセスして、50 リクエスト以内で問題を再現できます。そうは言っても、mysql の wait_timeout を増やして、Amazon RDS インスタンスを再起動しても無駄でした。
2) database.yml で「reconnect = true」。Aborted_clients がレール フロントエンドで対応する障害なしに成長することがあるため、これが問題を隠すのに役立つと思われます。
3）delayed_jobを無効にしました-おそらく遅延ジョブがエントリを破損していると考えて、それを無効にして問題を再度再現しました。
4) Amazon RDS インスタンスを小規模から中規模にアップグレードする - DB の負荷は非常に軽いですが、これが要因である可能性があると考えたため、Amazon RDS インスタンスを「小規模」から「中」にアップグレードしましたが、うまくいきませんでした。
5) ダッシュボード ページのクエリを単純化すると、そのページでエラーが再現される可能性は低くなりますが、エラーが完全になくなるわけではありません。
6）エラーが発生した場合、エラーはすぐに発生します-3〜5秒後ではなく、読み取り/書き込み/接続のタイムアウトではないと思います。
7) EC2 Web サーバーを再起動しても解決しない
8) Amazon RDS データベース インスタンスを再起動しても解決しない
9) ウェブサーバーにも Amazon RDS インスタンスにも大きな負荷がかからない
10) Web サーバーと RDS DB インスタンスの両方が同じアベイラビリティーゾーンにある
Rails の接続プール エントリが以前のクエリによって不適切な状態のままになっている可能性があり、その接続での次の試行がすぐに失敗する可能性があるように感じますが、それを証明する方法はありません。
また、Rails 4.0 には新しい Reaper の概念があり、定期的にプール エントリをチェックして接続が切れていないかどうかを確認しているようです。これはおそらく、Rails 4.0 で現在修正されている、より広範な問題であると思います。
これは現時点では実稼働環境でのみ再現可能であるため、mysql インスタンスを RDS から Web サーバーに移動して、RDS (リモート DB インスタンス) であるかどうかを分離することはできません。
次に何を試すべきかについて、Stack Overflow コミュニティからの意見はありますか?