RDS-MySQLサーバーの予期しないフェイルオーバー
16GBのRDS-MySQLマルチAZインスタンスがあります。最近、予期せず何度も失敗し、依存アプリケーションが15分以上オフラインになっています。
AWSサポートは、スワップ使用率が高いと非難しました。ただし、スワップ使用量が10 MBの場合、インスタンスは失敗しました。クエリの最適化を開始しました。
このような事故を回避するために他にできることはありますか？
================================================== =================
編集：
私たちは一つの観察をしました。インスタンスのCPU使用率はかなり低いままです。したがって、問題はディスクアクセスにある可能性があると推定しました。書き込みスループットは、読み取りスループットの数倍です。これに追加すると、Sort_merge_passesの値は79425になります（これはおかしいですよね？）。遅いクエリログを調べると、インデックスを使用しないORDER BY句を持つクエリが複数あることがわかりました。これらすべてのクエリの回避策が見つかるまでには時間がかかります。フェイルオーバーの問題を克服するための即時修正を提案できますか？ sort_buffer_sizeのグローバル値を増やす必要がありますか？現在の値は2MBです。
================================================== =========
編集2：
以下は、RDS-Performance Insightsで表示されるSort_Merge_Passes（クエリ/秒）の変化率のスクリーンショットです。
ご覧のように、負荷の期間中、値は0.5から1まで変化します（1より大きい値も観測されています）。クエリは複数のSort_merge_passesを引き起こす可能性があり、8が観察された最高値です。
================================================== =====================
編集3：
また、グローバルステータスCreated_tmp_disk_tablesが約2-3/second。正しく構造化されていないクエリだと思います。
- スワッピングは、RAMの過剰使用の悪い症状です。
- 過剰な数の同時接続がスワッピングにつながる可能性があります。
- 非常に複雑なクエリmayは、（一時テーブルのため）スワッピングにつながります。もしあれば、そのようなクエリを見てみましょう。
my.cnf（またはRDSの同等のもの）で何か変更を加えましたか？もしそうなら、いくつかの値を上げすぎていないか見てみましょう。簡単な修正として（およびRDSで許可されている場合）、
innodb_buffer_pool_sizeを1ギガバイト減らします。Sort_merge_passes-Uptimeで除算します。 1 /秒は「高」ですが、心配するほど高くはありません。- より詳細な分析については、 http://mysql.rjweb.org/doc.php/mysql_analysis を参照してください-グローバルステータスと変数がいくつかの手掛かりを見つける可能性があります。
pt-query-digestは、「最悪の」クエリに焦点を当てます。 sort_buffer_size = 2Mで結構です。- 「インデックスを使用しないORDER BY句」-クエリと
SHOW CREATE TABLEを表示します。