synch/cond/innodb/row_lock_wait_cond - Amazon Aurora
サポート対象エンジンバージョン待機時間が増加する原因の可能性アクション

synch/cond/innodb/row_lock_wait_cond

synch/cond/innodb/row_lock_wait_cond イベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。詳細については、MySQL リファレンスの InnoDB ロックを参照してください。

サポート対象エンジンバージョン

この待機イベント情報は、以下のエンジンバージョンでサポートされています。

  • Aurora MySQL バージョン 2

待機時間が増加する原因の可能性

複数のデータ操作言語 (DML) ステートメントが同じ行に同時にアクセスしようとしています。

アクション

確認できる他の待機イベントに応じて、異なるアクションをお勧めします。

この待機イベントを担当する SQL 文を見つけて応答します。

Performance Insights を使用して、この待機イベントの原因になっている SQL ステートメントを特定します。以下の戦略を検討して下さい。

  • 行のロックが永続的な問題である場合は、オプティミスティックロックを使用するようにアプリケーションを書き直すことを検討してください。

  • 複数行のステートメントの使用。

  • ワークロードを異なるデータベースオブジェクトに分散します。パーティショニングによって、これを行うことができます。

  • innodb_lock_wait_timeout パラメータの値をチェックしてください。これは、タイムアウトエラーを生成する前にトランザクションが待機する時間を制御します。

Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析 を参照してください。

ブロッキングセッションを見つけて対応する

ブロッキングセッションがアイドルかアクティブかを確認します。また、セッションがアプリケーションからかのものか、またはアクティブユーザーからのものであるかを調べます。

ロックを保持しているセッションを識別するには、SHOW ENGINE INNODB STATUS を実行します。次の例は サンプル出力を示しています。

mysql> SHOW ENGINE INNODB STATUS;

---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0

または、次のクエリを使用して、現在のロックの詳細を抽出することもできます。

mysql> SELECT p1.id waiting_thread,
              p1.user waiting_user,
              p1.host waiting_host,
              it1.trx_query waiting_query,        
              ilw.requesting_trx_id waiting_transaction, 
              ilw.blocking_lock_id blocking_lock, 
              il.lock_mode blocking_mode,
              il.lock_type blocking_type,
              ilw.blocking_trx_id blocking_transaction,
              CASE it.trx_state 
                WHEN 'LOCK WAIT' 
                THEN it.trx_state 
                ELSE p.state 
              END blocker_state, 
              il.lock_table locked_table,        
              it.trx_mysql_thread_id blocker_thread, 
              p.user blocker_user, 
              p.host blocker_host 
       FROM information_schema.innodb_lock_waits ilw 
       JOIN information_schema.innodb_locks il 
         ON ilw.blocking_lock_id = il.lock_id 
        AND ilw.blocking_trx_id = il.lock_trx_id
       JOIN information_schema.innodb_trx it 
         ON ilw.blocking_trx_id = it.trx_id
       JOIN information_schema.processlist p 
         ON it.trx_mysql_thread_id = p.id 
       JOIN information_schema.innodb_trx it1 
         ON ilw.requesting_trx_id = it1.trx_id 
       JOIN information_schema.processlist p1 
         ON it1.trx_mysql_thread_id = p1.id\G

*************************** 1. row ***************************
      waiting_thread: 3561959471
        waiting_user: reinvent
        waiting_host: 123.456.789.012:20485
       waiting_query: select id1 from test.t1 where id1=1 for update
 waiting_transaction: 312337314
       blocking_lock: 312337287:261:3:2
       blocking_mode: X
       blocking_type: RECORD
blocking_transaction: 312337287
       blocker_state: User sleep
        locked_table: `test`.`t1`
      blocker_thread: 3561223876
        blocker_user: reinvent
        blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)

セッションを特定する際、次のようなオプションが含まれます。

  • アプリケーションの所有者またはユーザーにお問い合わせください。

  • ブロッキングセッションがアイドル状態の場合は、ブロッキングセッションを終了することを検討してください。このアクションは、長いロールバックをトリガーする可能性があります。セッションの終了方法については、「セッションやクエリの終了」を参照してください。

ブロックトランザクションの識別の詳細については、MySQL リファレンスマニュアルの InnoDB トランザクションの使用とロック情報を参照してください。