synch/cond/sql/MDL_context::COND_wait_status
synch/cond/sql/MDL_context::COND_wait_status 이벤트는 테이블 메타데이터 잠금을 기다리는 스레드가 있는 경우 발생합니다.
지원되는 엔진 버전
이 대기 이벤트 정보는 다음 엔진 버전에서 지원됩니다.
-
Aurora MySQL 버전 2 및 3
컨텍스트
synch/cond/sql/MDL_context::COND_wait_status 이벤트는 테이블 메타데이터 잠금을 기다리는 스레드가 있음을 나타냅니다. 경우에 따라 한 세션이 테이블에 대해 메타데이터 잠금을 유지하고 다른 세션은 동일한 테이블에서 동일한 잠금을 가져오려고 시도합니다. 이 경우 두 번째 세션은 synch/cond/sql/MDL_context::COND_wait_status 대기 이벤트를 대기합니다.
MySQL은 메타데이터 잠금을 사용하여 데이터베이스 객체에 대한 동시 액세스를 관리하고 데이터 일관성을 보장합니다. 메타데이터 잠금은 get_lock 기능 및 저장된 프로그램을 통해 획득한 테이블, 스키마, 예약된 이벤트, 테이블스페이스 및 사용자 잠금에 적용됩니다. 저장된 프로그램에는 프로시저, 기능 및 트리거가 포함됩니다. 자세한 내용은 MySQL 설명서의 메타데이터 잠금
MySQL 프로세스 목록에는 이 세션이 waiting for metadata
lock 상태로 표시됩니다. 성능 개선 도우미에서, Performance_schema가 켜져 있는 경우 synch/cond/sql/MDL_context::COND_wait_status 이벤트가 발생합니다.
메타데이터 잠금을 기다리는 쿼리의 기본 시간 초과는 기본값이 31,536,000초(365일)인 lock_wait_timeout 파라미터 값을 기반으로 합니다.
서로 다른 InnoDB 잠금 및 충돌을 일으킬 수 있는 잠금 유형에 대한 자세한 내용은 MySQL 설명서에서 InnoDB 잠금
대기 증가의 가능한 원인
synch/cond/sql/MDL_context::COND_wait_status 이벤트가 정상보다 많이 나타나 성능 문제를 나타내는 경우 일반적인 원인은 다음과 같습니다.
- 장기 실행 트랜잭션
-
하나 이상의 트랜잭션이 대량의 데이터를 수정하고 오랜 시간 동안 테이블 잠금을 유지하고 있습니다.
- 유휴 트랜잭션
-
하나 이상의 트랜잭션이 커밋되거나 롤백되지 않고 오랫동안 열려 있습니다.
- 대형 테이블의 DDL 문
-
하나 이상의 데이터 정의 언어(DDL) 문(예:
ALTER TABLE명령)이 매우 큰 테이블에서 실행되었습니다. - 명시적 테이블 잠금
-
제때에 릴리스되지 않는 테이블에 대한 명시적 잠금이 있습니다. 예를 들어 애플리케이션이
LOCK TABLE문을 부적절하게 실행할 수 있습니다.
작업
대기 이벤트의 원인과 Aurora MySQL DB 클러스터 버전에 따라 다른 작업을 권장합니다.
이벤트를 일으키는 세션 및 쿼리 식별
성능 개선 도우미를 사용하여 synch/cond/sql/MDL_context::COND_wait_status 대기 이벤트에 의해 차단된 쿼리를 표시할 수 있습니다. 그러나 차단 세션을 식별하려면 DB 클러스터의 performance_schema 및 information_schema에서 메타데이터 테이블을 쿼리합니다.
일반적으로 보통 로드에서 중요 로드까지 있는 데이터베이스에는 대기 이벤트가 있습니다. 성능이 최적이면 대기 이벤트가 허용될 수 있습니다. 성능이 최적이 아닌 경우 데이터베이스가 가장 많은 시간을 소비하는 위치를 확인합니다. 가장 높은 로드를 일으키는 대기 이벤트를 살펴보고 데이터베이스와 애플리케이션을 최적화하여 이러한 이벤트를 줄일 수 있는지 확인합니다.
높은 로드에 책임이 있는 SQL 쿼리를 찾으려면
AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/
에서 Amazon RDS 콘솔을 엽니다. -
탐색 창에서 Performance Insights(성능 개선 도우미)를 선택합니다.
-
DB 인스턴스를 선택합니다. 해당 DB 인스턴스에 대한 성능 개선 도우미 대시보드가 표시됩니다.
-
데이터베이스 로드(Database load) 차트에서 대기별 조각(Slice by wait)을 선택합니다.
-
페이지 하단에서 상위 SQL(Top SQL)을 선택합니다.
차트에는 로드에 책임이 있는 SQL 쿼리가 나열됩니다. 목록의 맨 위에 있는 쿼리가 가장 큰 책임이 있습니다. 병목 현상을 해결하려면 다음 명령문에 집중하세요.
성능 개선 도우미를 통한 문제 해결에 대한 유용한 개요는 AWS 데이터베이스 블로그 게시물, 성능 개선 도우미를 통해 Amazon Aurora MySQL 워크로드 분석
지난 이벤트 확인
이 대기 이벤트에 대한 인사이트를 확보하여 과거의 발생을 확인할 수 있습니다. 이렇게 하려면 다음 작업을 완료합니다.
-
데이터 조작 언어(DML), DDL 처리량 및 대기 시간을 확인하여 워크로드에 변경 사항이 있는지 확인합니다.
성능 개선 도우미를 사용하여 문제 발생 시 이 이벤트에서 대기 중인 쿼리를 찾을 수 있습니다. 또한 문제 발생 시점에 실행되는 쿼리의 다이제스트도 볼 수 있습니다.
-
DB 클러스터에 대해 감사 로그 또는 일반 로그가 켜져 있는 경우 대기 트랜잭션과 관련된 객체(schema.table)에서 실행되는 모든 쿼리를 확인할 수 있습니다. 트랜잭션 전에 실행이 완료된 쿼리를 확인할 수도 있습니다.
과거 이벤트 문제를 해결하는 데 사용할 수 있는 정보는 제한되어 있습니다. 이러한 검사를 수행해도 어떤 객체가 정보를 대기하고 있는지는 표시되지 않습니다. 그러나 이벤트 발생 시 로드가 많은 테이블 및 문제 발생 시 충돌의 원인인 자주 작동하는 행 집합을 식별할 수 있습니다. 그런 다음 이 정보를 사용하여 테스트 환경에서 문제를 재현하고 그 원인에 대한 인사이트를 제공할 수 있습니다.
Aurora MySQL 버전 2에서 쿼리 실행
Aurora MySQL 버전 2에서는 performance_schema 테이블 또는 sys 스키마 보기를 쿼리하여 차단된 세션을 직접 식별할 수 있습니다. 예를 들어 차단 쿼리 및 세션을 식별하려면 테이블을 쿼리하는 방법을 설명할 수 있습니다.
다음 프로세스 목록 출력에서 연결 ID 89는 메타 데이터 잠금을 기다리고 있으며 TRUNCATE TABLE 명령을 실행하고 있습니다. performance_schema 테이블 또는 sys 스키마 보기에 대한 쿼리에서 출력은 차단 세션이 76임을 표시합니다.
MySQL [(none)]> select @@version, @@aurora_version; +-----------+------------------+ | @@version | @@aurora_version | +-----------+------------------+ | 5.7.12 | 2.09.0 | +-----------+------------------+ 1 row in set (0.01 sec) MySQL [(none)]> show processlist; +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL | | 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL | | 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL | | 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL | | 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL | | 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL | | 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL | | 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL | | 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL | | 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL | | 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL | | 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL | | 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL | | 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist | | 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) | | 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ 18 rows in set (0.00 sec)
다음으로, performance_schema 테이블 또는 sys 스키마 보기에 대한 쿼리는 차단 세션이 76임을 표시합니다.
MySQL [(none)]> select * from sys.schema_table_lock_waits; +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ 1 row in set (0.00 sec)
차단 세션에 대한 응답
세션을 식별할 때 옵션에는 다음이 포함됩니다.
-
애플리케이션 소유자 또는 사용자에게 문의하세요.
-
차단 세션이 유휴 상태인 경우 차단 세션을 종료하는 것이 좋습니다. 이 작업은 긴 롤백을 트리거할 수 있습니다. 세션을 종료하는 방법에 대한 내용은 세션 또는 쿼리 종료를 참조하세요.
차단 트랜잭션 식별에 대한 자세한 내용은 MySQL 설명서에서 InnoDB 트랜잭션 및 잠금 정보 사용
