Aurora MySQL 대기 이벤트

실행할 준비가 된 활성 연결 수는 vCPU 수보다 일관되게 많습니다. 자세한 내용은 cpu 단원을 참조하십시오.

세션은 Aurora 스토리지에 데이터를 유지하고 있습니다. 일반적으로 이 대기 이벤트는 Aurora MySQL의 쓰기 I/O 작업을 위한 것입니다. 자세한 내용은 io/aurora_redo_log_flush 단원을 참조하십시오.

쿼리 처리가 완료되었으며 2.10.2 이상 2.10 버전, 2.09.3 이상 2.09 버전, 2.07.7 이상 2.07 버전과 같은 Aurora MySQL 버전에 대한 결과가 애플리케이션 클라이언트에 반환됩니다. DB 인스턴스 클래스의 네트워크 대역폭을 반환되는 결과 집합의 크기와 비교합니다. 또한 클라이언트측 응답 시간도 확인합니다. 클라이언트가 응답하지 않고 TCP 패킷을 처리할 수 없는 경우 패킷이 삭제되고 TCP가 재전송될 수 있습니다. 이러한 상황은 네트워크 대역폭에 부정적인 영향을 미칩니다. 2.10.2, 2.09.3 및 2.07.7 이전 버전에서는 이 대기 이벤트에 유휴 시간이 잘못 포함됩니다. 이 대기 시간이 눈에 띄게 표시되는 경우 데이터베이스를 튜닝하는 법을 알아보려면 io/aurora_respond_to_client 섹션을 참조하세요.

스레드는 쉼표로 구분된 값(CSV) 형식으로 테이블에 작성합니다. CSV 테이블 사용을 확인하세요. 일반적으로 이 이벤트는 테이블에서 log_output을 설정하는 중에 발생합니다.

스레드는 디스크에 기록 중인 이진 로그(binlog) 파일에서 대기 중입니다.

세션은 Aurora 스토리지에 데이터를 유지하고 있습니다. 일반적으로 이 대기 이벤트는 Aurora MySQL의 쓰기 I/O 작업을 위한 것입니다. 자세한 내용은 io/redo_log_flush 단원을 참조하십시오.

mysqld 프로그램은 들어오는 새 클라이언트 연결을 처리하기 위해 스레드를 만드는 중입니다. 자세한 내용은 io/socket/sql/client_connection 단원을 참조하십시오.

엔진이 테이블에 대한 액세스를 기다리고 있습니다. 이 이벤트는 데이터가 버퍼 풀에 캐시되는지 디스크에 액세스되는지 관계없이 발생합니다. 자세한 내용은 io/table/sql/handler 단원을 참조하십시오.

이 대기 이벤트는 테이블 잠금 대기 이벤트 핸들러입니다. 성능 스키마의 atom 및 molecule 이벤트에 대한 자세한 내용은 MySQL 설명서의 성능 스키마 Atom 및 Molecule 이벤트를 참조하세요.

여러 데이터 조작 언어(DML) 문이 동시에 동일한 데이터베이스 행에 액세스하고 있습니다. 자세한 내용은 synch/cond/innodb/row_lock_wait 단원을 참조하십시오.

여러 DML 문이 동시에 동일한 데이터베이스 행에 액세스하고 있습니다. 자세한 내용은 synch/cond/innodb/row_lock_wait_cond 단원을 참조하십시오.

스레드가 테이블 메타데이터 잠금을 기다리는 중입니다. 엔진이 이러한 유형의 잠금을 사용하여 데이터베이스 스키마에 대한 동시 액세스를 관리하고 데이터 일관성을 보장합니다. 자세한 내용은 MySQL 설명서의 잠금 작업 최적화를 참조하세요. 이 이벤트가 눈에 띄게 표시되는 경우 데이터베이스를 튜닝하는 법을 알아보려면 synch/cond/sql/MDL_context::COND_wait_status 섹션을 참조하세요.

이진 로깅을 설정했습니다. 높은 커밋 처리량, 많은 커밋 트랜잭션 또는 binlog를 읽는 복제본이 있을 수 있습니다. 다중 행 문을 사용하거나 명령문을 하나의 트랜잭션에 번들링하는 것이 좋습니다. Aurora에서는 이진 로그 복제 대신 글로벌 데이터베이스를 사용하거나 aurora_binlog_* 파라미터를 사용합니다.

여러 DML 문이 동시에 동일한 데이터베이스 행에 액세스하고 있습니다. 자세한 내용은 synch/mutex/innodb/aurora_lock_thread_slot_futex 단원을 참조하십시오.

버퍼 풀은 작업 중인 데이터 세트를 보유하기에 충분하지 않습니다. 또는 워크로드가 특정 테이블의 페이지에 액세스하여 버퍼 풀에서 경합이 발생합니다. 자세한 내용은 synch/mutex/innodb/buf_pool_mutex 단원을 참조하십시오.

프로세스가 테이블스페이스 메모리 캐시에 대한 액세스를 기다리고 있습니다. 자세한 내용은 synch/mutex/innodb/fil_system_mutex 단원을 참조하십시오.

작업은 일관되거나 제어된 방식으로 InnoDB의 트랜잭션 ID를 확인, 업데이트, 삭제 또는 추가하는 것입니다. 이러한 작업에는 성능 스키마 계측을 통해 추적되는 trx_sys 뮤텍스 호출이 필요합니다. 작업에는 데이터베이스가 시작하거나 종료할 때 트랜잭션 시스템 관리, 롤백, 실행 취소 정리, 행 읽기 액세스 및 버퍼 풀 로드 등이 포함됩니다. 많은 수의 트랜잭션을 통한 데이터베이스 로드가 많으면 이 대기 이벤트가 자주 표시됩니다. 자세한 내용은 synch/mutex/innodb/trx_sys_mutex 단원을 참조하십시오.

keycache->cache_lock 뮤텍스는 MyISAM 테이블의 키 캐시에 대한 액세스를 제어합니다. Aurora MySQL에서는 영구 데이터를 저장하는 데는 MyISAM 테이블을 사용할 수 없지만 내부 임시 테이블을 저장하는 데는 사용됩니다. 특정 상황에서는 임시 테이블이 더 이상 메모리에 들어가지 않을 때 디스크에 기록되므로 created_tmp_tables 또는 created_tmp_disk_tables 상태 카운터를 확인하는 것이 좋습니다.

엔진은 테이블 메타데이터 파일을 열거나 생성할 때 이 뮤텍스를 가져옵니다. 이 대기 이벤트가 과도한 빈도로 발생하면 생성되거나 열려 있는 테이블 수가 급증합니다.

엔진은 열린 테이블을 추적하는 내부 구조에서 reset_size, detach_contents 또는 add_contents와 같은 작업을 수행하는 동안 이 뮤텍스를 가져옵니다. 뮤텍스는 목록 내용에 대한 액세스를 동기화합니다. 이 대기 이벤트가 높은 빈도로 발생하면 이전에 액세스한 테이블 집합이 갑자기 변경되었음을 나타냅니다. 엔진은 새 테이블에 액세스하거나 이전에 액세스한 테이블과 관련된 컨텍스트를 제거해야 합니다.

세션에서 열리는 테이블 수가 테이블 정의 캐시 또는 테이블 열기 캐시의 크기를 초과합니다. 이러한 캐시의 크기를 늘립니다. 자세한 내용은 MySQL에서 테이블을 열고 닫는 방법을 참조하세요.

세션에서 열리는 테이블 수가 테이블 정의 캐시 또는 테이블 열기 캐시의 크기를 초과합니다. 이러한 캐시의 크기를 늘립니다. 자세한 내용은 MySQL에서 테이블을 열고 닫는 방법을 참조하세요.

이 대기 이벤트에서는 로그 잠금을 대기 중인 스레드가 있습니다. 예를 들어, 스레드가 느린 쿼리 로그에 쓰기 위해 잠금을 대기 중일 수 있습니다.

이 대기 이벤트에서는 바이너리 로그에 커밋할 목적으로 잠금 획득을 대기 중인 스레드가 있습니다. 변경률이 매우 높은 데이터베이스에서 바이너리 로깅 경합이 발생할 수 있습니다. MySQL의 버전에 따라 바이너리 로그의 일관성과 내구성을 보호하기 위해 사용 중인 특정 잠금이 있습니다. RDS for MySQL에서는 복제 및 자동 백업 과정에 바이너리 로그가 사용됩니다. Aurora MySQL에서는 기본 복제 또는 백업에 바이너리 로그가 사용되지 않습니다. 바이너리 로그는 기본적으로 비활성화되지만, 활성화한 후 외부 복제 또는 변경 데이터 캡처에 사용할 수 있습니다. 자세한 내용은 MySQL 설명서의 바이너리 로그를 참조하십시오.

이진 로깅이 설정되어 있으면 엔진은 활성 덤프 스레드 지표를 엔진 오류 로그와 내부 작업 맵에 인쇄할 때 이 뮤텍스를 가져옵니다.

이진 로깅이 설정되어 있으면 엔진이 최신 파일 뒤에 있는 binlog 파일 목록을 통해 추가, 삭제 또는 검색할 때 이 뮤텍스를 가져옵니다.

이진 로깅이 설정되어 있으면 Aurora binlog IO 캐시 작업(캐시 정보 할당, 크기 조정, 해제, 쓰기, 읽기, 제거 및 액세스) 중에 엔진이 이 뮤텍스를 획득합니다. 이 이벤트가 자주 발생하면 엔진은 binlog 이벤트가 저장되는 캐시에 액세스합니다. 대기 시간을 줄이려면 커밋을 줄이세요. 여러 명령문을 단일 트랜잭션으로 그룹화해 보세요.

이진 로깅을 설정했습니다. 높은 커밋 처리량, 많은 커밋 트랜잭션 또는 binlog를 읽는 복제본이 있을 수 있습니다. 다중 행 문을 사용하거나 명령문을 하나의 트랜잭션에 번들링하는 것이 좋습니다. Aurora에서는 이진 로그 복제 대신 글로벌 데이터베이스를 사용하거나 aurora_binlog_* 파라미터를 사용합니다.

파일 쓰기를 위해 스레드를 스케줄링, 처리 또는 시작하는 동안 SERVER_THREAD::LOCK_sync 뮤텍스를 가져옵니다. 이 대기 이벤트가 과도하게 발생하면 데이터베이스에서 쓰기 작업이 증가했다는 것을 나타냅니다.

엔진이 다음과 같은 테이블스페이스 작업(생성, 삭제, 자르기 및 확장) 중에 TABLESPACES:lock 뮤텍스를 가져옵니다. 이 대기 이벤트가 과도하게 발생하면 테이블스페이스 작업의 빈도가 높다는 것을 나타냅니다. 예를 들어 대량의 데이터를 데이터베이스에 로드하는 것입니다.

이 대기 이벤트에서는 InnoDB 데이터 딕셔너리에 보관된 rwlock을 대기 중인 스레드가 있습니다.

이 대기 이벤트에서는 InnoDB 데이터 딕셔너리 작업에 대한 잠금을 보유한 스레드가 있습니다.

데이터 정의 언어(DDL) 코드에서 많은 수의 동시 데이터 제어 언어(DCL) 문이 동시에 트리거됩니다. 정기적인 애플리케이션 작업 중에 DDL에 대한 애플리케이션의 종속성을 줄입니다.

많은 수의 비슷한 데이터 조작 언어(DML) 문이 동시에 동일한 데이터베이스 객체에 액세스하고 있습니다. 다중 행 문을 사용해 보세요. 또한 서로 다른 데이터베이스 객체에 워크로드를 분산하세요. 예를 들어 파티셔닝을 구현합니다.

데이터 정의 언어(DDL) 코드에서 많은 수의 동시 데이터 제어 언어(DCL) 문이 동시에 트리거됩니다. 정기적인 애플리케이션 작업 중에 DDL에 대한 애플리케이션의 종속성을 줄입니다.

데이터 정의 언어(DDL) 코드에서 많은 수의 동시 데이터 제어 언어(DCL) 문이 동시에 트리거됩니다. 정기적인 애플리케이션 작업 중에 DDL에 대한 애플리케이션의 종속성을 줄입니다.

세션이 버퍼 풀에서 페이지를 찾을 수 없습니다. 엔진은 파일을 읽거나 버퍼 풀의 LRU(least-recently used) 목록을 수정해야 합니다. 버퍼 캐시 크기를 늘리고 관련 쿼리에 대한 액세스 경로를 개선하는 것이 좋습니다.

많은 수의 비슷한 데이터 조작 언어(DML) 문이 동시에 동일한 데이터베이스 객체에 액세스하고 있습니다. 다중 행 문을 사용해 보세요. 또한 서로 다른 데이터베이스 객체에 워크로드를 분산하세요. 예를 들어 파티셔닝을 구현합니다.