このトピックでは、Database Autonomy Service (DAS) のロック分析機能を使用して、データベースのデッドロック分析を実行する方法について説明します。最近のデッドロック分析と全量デッドロック分析の 2 つのモードについて説明します。
このトピックの図に含まれるスレッド ID や SQL ステートメントなどのデータは、デモンストレーションのみを目的としています。操作を実行する際は、実際のデータとパラメーターを使用してください。
前提条件
-
ターゲットインスタンスは、次のいずれかのエンジンを使用している必要があります。
-
最近のデッドロック分析:
-
RDS MySQL
-
セルフマネージド MySQL
-
PolarDB for MySQL
-
PolarDB-X 2.0
-
-
全量デッドロック分析:
-
RDS MySQL
-
PolarDB for MySQL
-
-
-
ターゲットインスタンスが DAS に接続されており、接続ステータスが [正常なアクセス] である必要があります。詳細については、「データベースインスタンスの DAS への接続」をご参照ください。
-
Alibaba Cloud Managed Services (旧 DAS Economy Edition) が有効になっている必要があります。
重要-
Alibaba Cloud Managed Services は、特定のリージョンでのみ利用可能です。詳細については、「エディション別のサポート対象データベースとリージョン」をご参照ください。
-
このサービスを有効にするには、「Alibaba Cloud Managed Services の管理」をご参照ください。
-
最近のデッドロック分析
-
パラメーター設定: インスタンスは
innodb_deadlock_detectパラメーターが有効になっている必要があります。説明このパラメーターは通常、デフォルトで有効になっています。これを確認するには、
SHOW VARIABLES LIKE 'innodb_deadlock_detect'を実行します。一部のインスタンスタイプでは、このパラメーターの値を変更できないことに注意してください。-
インスタンスのパラメーターを変更するには:
-
RDS MySQL の場合は、「インスタンスパラメーターの設定」をご参照ください。
-
PolarDB for MySQL の場合は、「クラスターおよびノードパラメーターの設定」をご参照ください。
-
-
-
データ分析:
SHOW ENGINE INNODB STATUSコマンドによって返された最新のデッドロックログを分析します。
複数のデッドロックが発生した場合、各分析は最新のデッドロックのみをキャプチャし、そのデータを保存します。
手順
にログインします。DASコンソール.
左側のナビゲーションウィンドウで、インスタンスモニター.
表示されるページで、管理するデータベースインスタンスを見つけ、インスタンスIDをクリックします。 インスタンス詳細ページが表示されます。
-
左側メニューで [ロック分析] をクリックします。[ロック分析] ページで、[最近のデッドロック分析] タブを選択します。
-
[分析の作成] をクリックして、最近のデッドロック分析を開始します。
分析が完了すると、[最近のデッドロック分析] タブの結果テーブルに、生成時間、発生時間、およびデッドロックが検出されたかどうかが表示されます。[詳細の表示] をクリックすると、デッドロックに関する詳細情報が表示されます。
詳細の表示
-
期間を選択して、その期間内に実行された分析タスクの結果を表示します。
-
最近のデッドロック分析の分析タスク一覧で、[詳細] 列の [詳細の表示] をクリックします。
-
パネルが表示され、デッドロックの詳細が 3 つのタブに表示されます。
-
[表示]:関連するトランザクションとレコードロックのノードを含む、デッドロック関係の視覚的なグラフを表示します。ロックが付与されました と 待機中 を示す矢印は、ロックの所有と待機の関係を示し、デッドロックサイクルを形成します。ロールバックされたトランザクションは「ロールバック済み」とマークされます。トランザクションノードをクリックすると、セッション ID、スレッド ID、リクエストタイプ、トランザクション ID、関連テーブル、待機ロック情報、待機ロック上のインデックス名などの詳細が展開されます。
-
[一覧]:このタブでは、デッドロック状態にある 2 つのトランザクションを並べて比較表示します。ロールバックされたトランザクションにはマークが付きます。テーブルの行には、セッション ID、スレッド ID、リクエストタイプ、トランザクション ID、関連テーブル、待機ロック (インデックス名とロックタイプ、例:X locks rec but not gap waiting)、保持ロック (インデックス名とロックタイプ)、およびトランザクション SQL が含まれます。下部では、スレッド ID またはトランザクション ID を使用して、[SQL Explorer と監査] で関連するトランザクションの詳細を検索できます。
-
ログ:
SHOW ENGINE INNODB STATUSの出力のLATEST DETECTED DEADLOCKセクションから、デッドロックの生ログ詳細を表示します。 これには、デッドロックが発生した時刻、関連するトランザクションの SQL ステートメント、保持しているロック情報 (HOLDS THE LOCK)、および待機しているロック情報 (WAITING FOR THIS LOCK TO BE GRANTED) が含まれます。
-
SQL Explorer と監査による分析
-
ターゲットインスタンスの左側メニューで [SQL Explorer と監査] をクリックします。[監査] ページで [高度なクエリを有効化] をクリックします。
-
デッドロックが発生した時間を含む時間範囲を選択し、最近のデッドロック分析から取得したスレッド ID を入力して、そのトランザクションが実行した SQL ステートメントをクエリします。
-
例のトランザクション 1 の場合、クエリ結果は、スレッドが 3 つの SQL ステートメント (
update students set name=UUID() where id = 2(実行時間:2,938.377 ms、ロック待機時間:1 ms)、update students set name=UUID() where id = 3(実行時間:0.002 ms)、およびbegin) を実行したことを示しています。最初の update ステートメントの実行時間が異常に長いのは、ロック待機を示しています。 -
トランザクション 2 (ロールバック済み) の場合:[監査] ページで、[時間範囲] を設定し、[スレッド ID] を
195662に設定してから、[クエリ] をクリックします。ログ一覧には、トランザクション 2 の SQL 実行レコードが表示されます。update students set name=UUID() where id = 3はエラーコード 1213 (デッドロック) で失敗し、1.40 ms かかりました (ロック待機時間は 1.152 ms)。update students set name=UUID() where id = 2は成功し、0.20 ms かかりました。beginは成功し、0.18 ms かかりました。
-
全量デッドロック分析
-
innodb_deadlock_detectおよびinnodb_print_all_deadlocksパラメーターを有効にする必要があります。RDS MySQL インスタンスの場合、log_error_verbosityパラメーターを 3 に設定する必要があります。説明innodb_deadlock_detectパラメーターは通常デフォルトで有効になっており、SHOW VARIABLES LIKE 'innodb_deadlock_detect'を実行して確認できます。なお、一部のインスタンスタイプではこのパラメーターの値を変更できません。-
インスタンスのパラメーターを変更するには:
-
RDS MySQL の場合は、「インスタンスパラメーターの設定」をご参照ください。
-
PolarDB for MySQL の場合は、「クラスターおよびノードパラメーターの設定」をご参照ください。
-
-
-
データソース:この機能は、インスタンスのエラーログに記録されたデッドロック情報を 1 時間ごとに解析し、デッドロック数の傾向を生成し、各デッドロックの詳細を収集します。
-
クールダウン期間:Alibaba Cloud Managed Services が有効な状態で、DAS が必要なパラメーターが有効になっていないことを検出した場合、DAS は 12 時間のクールダウン期間に入り、分析タスクを実行しません。クールダウン期間中に必要なパラメーターを有効にすると、DAS は期間が終了するのを待ってから分析を再スケジュールします。例:
-
11:12 の分析タスクで、必要なパラメーターが有効になっていないことが検出されると、12 時間のクールダウンが開始されます。23:12 以降、全量デッドロック分析はタスクを再スケジュールします。パラメーターがまだ有効になっていない場合、さらに 12 時間のクールダウンが開始されます。23:12 より前にパラメーターを有効にすると、クールダウンは 23:12 に終了します。その後、必要なパラメーターと Alibaba Cloud Managed Services がインスタンスで有効なままであれば、分析は 1 時間ごとに実行されます。
-
メッセージ「TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION」を含むデッドロックの分析はサポートされていません。
手順
にログインします。DASコンソール.
左側のナビゲーションウィンドウで、インスタンスモニター.
表示されるページで、管理するデータベースインスタンスを見つけ、インスタンスIDをクリックします。 インスタンス詳細ページが表示されます。
-
左側メニューで [ロック分析] をクリックします。[ロック分析] ページで、[全量デッドロック分析] タブを選択します。
-
全量デッドロック分析は、1 時間ごとにインスタンスのエラーログを自動的に分析し、デッドロックをカウントして、ページ上部の [デッドロックの傾向] グラフにデータをプロットします。期間を選択すると、その期間のデッドロックの傾向が表示されます。
ページの上部には、[過去 1 日間]、[過去 3 日間]、[過去 7 日間] のクイック選択ボタンと、カスタムの日付範囲セレクターがあります。[表示] ボタンをクリックして、傾向グラフを更新します。グラフの下には、各デッドロックイベントの [デッドロック時間] を示すリストがあります。特定のイベントの [詳細の表示] をクリックすると、詳細情報が表示されます。
詳細の表示
-
全量デッドロック分析のデッドロック一覧で、詳細 列の 詳細を見る をクリックします。
-
パネルが表示され、デッドロックの詳細が [表示]、[一覧]、[ログ] の 3 つのタブに表示されます。[ログ] タブには、デッドロックに関連するエラーログの内容が含まれています。[表示] タブと [一覧] タブは、最近のデッドロック分析のものと同じです。詳細については、「最近のデッドロック分析 - 詳細の表示」をご参照ください。
SQL Explorer と監査による分析
手順は最近のデッドロック分析と同じです。詳細については、「最近のデッドロック分析 - SQL Explorer と監査による分析」をご参照ください。