tencent cloud

##故障について
TencentDB for MySQLにレスポンスの低下、接続を取得できない、タイムアウトなどの現象が発生します。TencentDB for MySQL CPU使用率が80％を超えると、レスポンスの低下、タイムアウト、データベースへの接続不可などの現象が発生することがあります。

TencentDB for MySQL CPU使用状況は、MySQLコンソールのインスタンス監視ページまたはTencentDB for DBbrain DBbrainコンソール で確認することができます。

説明：

CPU使用率が高すぎる場合は、構成の調整を優先し、CPU仕様を上げてサービスの正常な動作を確保することをお勧めします。その後で、このドキュメントを参照してトラブルシューティングと最適化を行うことができます。

故障リスク

MySQL CPU使用率が長時間にわたって高すぎると、データベース全体のパフォーマンスに深刻な影響を及ぼし、極端な場合には、インスタンスがHANGする状況が発生することがあります。

HAはインスタンスがHANGしていることを検出すると、ユーザー業務の高可用性を保証するために、マスター/スレーブの切り替えを行います。マスター/スレーブの切り替えプロセス中はサービスが短時間使用できなくなります。通常、インスタンスが使用できない時間は60秒を超えることはありません。業務ピーク時にマスター/スレーブの切り替えが発生すると、業務の安定性と継続性に深刻な影響を及ぼす恐れがあります。

CPUリソース不足によるビジネスへの影響を避けるために、CPU使用率が高いインスタンスを事前に最適化するか、またはCPUリソースをアップグレードすることをお勧めします。マスターインスタンスとスレーブインスタンスを切り替えると、数秒間の短い中断が発生する場合があります。長時間接続のためにはアプリケーションに再接続機能を備えておく必要があります。

考えられる原因

MySQLは主に、システムスレッドとユーザースレッドの2種類のスレッドを使用してCPUを占有します。従って、MySQLが独占するCVMでは、これら2種類のスレッドの状況に注意を払うだけで、ほとんどの障害シナリオを解決することができます。

ユーザースレッド

ユーザースレッドがビジーである場合、大部分のシナリオは「スロークエリー」によって引き起こされます。「スロークエリー」要因に加えて、「多い計算量」と「高QPS」要因も存在します。

• スロークエリー
  order by、group by、一時テーブル、joinなど、長時間の計算を実行します。このタイプの問題では、クエリーの効率が低く、単一のSQLセンテンスが長時間にわたりCPU時間を占有します。
• 多い計算量
  単純なデータ量が多いと、計算量が膨大になります。
• 高QPS(Queries Per Second)
  単純なQPS負荷が高いために、CPUの時間を使い果たします。例えば、4コアのサーバーは、20kから30kポイントのクエリーをサポートするために使用されます。各SQLが占有するCPU時間は長くありませんが、全体的なQPSが非常に高いために、CPU時間が完全に占有されます。

システムスレッド

実際の環境では、システムスレッドに問題が発生する頻度は低くなります。通常、複数のシステムスレッドが同時にフルに実行されることはほとんどありません。CVMの使用可能なコア数が4以上であれば、通常はCPU使用率が高くなりすぎることはありません。もちろん、次の図に示すように、一部のbugが影響を及ぼす可能性はあります。

ソリューション

大部分の障害シナリオは、基本的にユーザースレッドのビジーによって引き起こされるため、ここでは、主にユーザースレッドによって引き起こされるCPU使用率が高すぎる問題について説明し、それに対応するソリューションを提供します。

• スロークエリー：調査と最適化のためにDBbrainを使用することをお勧めします。詳細はスロークエリーをご参照ください。
• 多い計算量：データ処理量が多いため、CPU使用率が高くなりすぎます。処理方法の詳細については、多い計算量をご参照ください。
• 高QPS：アクセス量が多すぎるため、CPU使用率が高くなりすぎます。対処方法の詳細は高QPSをご参照ください。

処理手順

スロークエリー

CPU使用率が高くなりすぎる異常なSQLセンテンスは、TencentDB for DBbrainを使用して、調査し最適化することができます。

• 異常診断 (推奨): 7 * 24時間対応の異常発見診断は、リアルタイムでの最適化の提案を提供します。操作の詳細については、 「異常診断」機能を使用したデータベース異常の調査をご参照ください。
• 低速SQL分析：現在のインスタンスに発生した低速SQLを分析し、低速SQLの最適化の提案を行います。操作の詳細については、 「低速SQL分析」機能を使用した高すぎるCPU使用率を引き起こすSQLの調査」をご参照ください。
• 監査ログ分析: クラウドデータベース監査データ(フルSQL) を使用し、SQLセンテンスを多次元的に掘り下げて分析すると同時に、最適化の提案を行います。 操作の詳細については、 「監査ログ分析」機能を使用した高すぎるCPU使用率を引き起こすSQLの調査をご参照ください。

MySQLスロークエリ時間(long_query_time)のデフォルト値は10sですが、パフォーマンスの問題が発生した後、スロークエリが見つからない場合は、そのパラメータ値を1sに調整し、ビジネスサイクルにスロークエリがあるかどうかを確認し、ある場合はそれに応じてスロークエリを最適化することをお勧めします。パラメータを調整した後、スロークエリが見つからないのにCPU使用率が高いままである場合は、データベースの全体的なパフォーマンスを向上させるためにCPU設定をアップグレードすることをお勧めします。

多い計算量

データ量が多いと、インデックスや実行計画に問題がなくともCPU使用率が高くなりすぎてしまうこと、さらにMySQL one-thread-per-connectionの特性を踏まえれば、同時実行数がそれほど多くなくともCPU使用率がフルになることがあります。

通常、これらの問題には、次の2つの標準的なソリューションがあります。

• 読み取りと書き込みを分離し、通常の業務ではあまり使用しない読み取り専用のスレーブライブラリにこのタイプのクエリーを配置します。
• プログラムセグメントでSQLを分割し、1つの大きなクエリーを複数の小さなクエリーに分割します。

高QPS

• CPUの設定をアップグレードし、データベースの全体的なパフォーマンスを向上させます。
• 読み取り専用インスタンスをマウントして、マスターインスタンスの負荷を分散させます。
• クエリーセンテンスを最適化し、実行効率を向上させます。