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 문을 찾아 응답합니다.

성능 개선 도우미를 사용하여 이 대기 이벤트를 담당하는 SQL 문을 식별합니다. 다음과 같은 전략을 생각해 보세요.

  • 행 잠금이 지속적으로 문제가 되는 경우 낙관적 잠금을 사용하도록 애플리케이션을 다시 작성하는 것이 좋습니다.

  • 다중 명령문을 사용합니다.

  • 서로 다른 데이터베이스 객체에 워크로드를 분산합니다. 파티셔닝을 통해 이를 수행할 수 있습니다.

  • innodb_lock_wait_timeout 파라미터 값을 확인하세요. 시간 초과 오류가 발생하기 전에 트랜잭션이 대기하는 시간을 제어합니다.

성능 개선 도우미를 통한 문제 해결의 개요는 블로그 게시물, 성능 개선 도우미를 통해 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 트랜잭션 및 잠금 정보 사용을 참조하세요.