활동 추적 및 추적

  • 11분

데이터베이스 유지 관리의 상당 부분은 성능 튜닝입니다. 온-프레미스 데이터베이스에서 검토하는 데 사용한 것과 동일한 로그 파일은 Azure Database for MySQL/PostgreSQL에서 계속 사용할 수 있습니다.

데이터베이스가 Azure로 마이그레이션되면 로그 파일을 계속 검토하여 데이터베이스의 성능이 유지되는지 확인해야 합니다.

이 단원에서는 PostgreSQL 및 MySQL에 대한 로그 파일이 Azure에 저장되는 위치와 포함된 세부 수준을 확인할 수 있습니다.

서버 로그를 사용하여 데이터베이스 활동 추적

Azure Database for MySQL/PostgreSQL도 서버 로그에 진단 정보를 기록합니다. 서버 로그는 MySQL 및 PostgreSQL에 대한 네이티브 메시지 로그 파일입니다(Azure Database for MySQL/PostgreSQL에서 액세스할 수 없는 트랜잭션 로그 파일이 아님). 이러한 파일에는 데이터베이스 문제를 디버그하는 데 사용하는 메시지, 서버 상태 및 기타 오류 정보가 포함됩니다. 서버 로그는 최대 7일 동안 유지됩니다(서버 로그 파일의 총 크기가 7GB를 초과하는 경우 작음).

Azure Database for MySQL 및 Azure Database for PostgreSQL은 서버 로그에 다른 세부 정보를 기록합니다. 다음 섹션에서는 각 서비스에 대한 서버 로그를 개별적으로 설명합니다.

Azure Database for MySQL의 서버 로그

Azure Database for MySQL에서 서버 로그는 느린 쿼리 로그 일반적으로 사용할 수 있는 정보와 MySQL 서버의 감사 로그 제공합니다.

느린 쿼리 로그의 정보를 사용하여 느리게 실행되는 쿼리를 식별할 수 있습니다. 기본적으로 느린 쿼리 로그는 사용하지 않도록 설정되어 있습니다. slow_query_log 서버 매개 변수를 ON 설정하여 사용하도록 설정합니다. 다음 서버 매개 변수를 사용하여 느린 쿼리 의미를 결정하도록 느린 쿼리 로그를 구성합니다.

  • log_queries_not_using_indexes. 이 매개 변수는 ON 또는 OFF . 인덱스 조회가 아닌 전체 테이블 검색을 수행할 가능성이 있는 모든 쿼리를 기록하도록 on 설정합니다.
  • log_throttle_queries_not_using_indexes. 분당 기록할 수 있는 인덱스를 사용하지 않는 느린 쿼리의 최대 수를 지정합니다.
  • log_slow_admin_queries. 이 매개 변수를 ON 설정하여 느리게 실행되는 관리 쿼리를 로그에 포함합니다.
  • long_query_time. 쿼리가 느리게 실행되는 고려되는 임계값(초)입니다.

느린 쿼리 로그 및 감사 로그를 사용하도록 설정하면 로그 파일이 서버의 서버 로그 페이지에 표시되기 시작합니다. 매일 새 느린 쿼리 로그가 만들어집니다. 로그 파일을 클릭하여 다운로드합니다.

Azure Database for MySQL에 대한 서버 로그 페이지의 이미지입니다.

감사 로깅을 사용하도록 설정하려면 audit_log_enabled 서버 매개 변수를 ON 설정합니다. 다음 매개 변수를 사용하여 감사 로깅을 구성합니다.

  • audit_log_events. 감사할 이벤트를 지정합니다. Azure Portal에서 이 매개 변수는 CONNECTION, DDL, DML, ADMIN등의 이벤트 드롭다운 목록을 제공합니다.
  • audit_log_exclude_users. 이 매개 변수는 감사 로그에 활동이 포함되지 않는 쉼표로 구분된 사용자 목록입니다.

느린 쿼리 로그 및 감사 로그를 7일 이상 유지해야 하는 경우 Azure Storage로 전송되도록 정렬합니다. 서버에 대한 진단 설정 페이지를 사용한 다음, + 진단 설정추가를 선택합니다. 진단 설정 페이지에서 스토리지 계정 보관을 선택하고, 로그 파일을 저장할 스토리지 계정(이 스토리지 계정이 이미 있어야 함)을 선택하고, MySqlSlowLogs 선택하고, MySqlAuditLogs , 최대 365일의 보존 기간을 지정합니다. 이 시간 동안 언제든지 Azure Storage에서 로그 파일을 다운로드할 수 있습니다. 저장을 선택합니다.

Azure Database for MySQL에 대한 진단 설정 페이지의 이미지입니다.

느린 쿼리 로그 데이터는 insights-logs-mysqlslowlogs컨테이너의 Blob에 JSON 형식으로 기록됩니다. 로그 파일이 Azure Storage에 표시되는 데 최대 10분이 걸릴 수 있습니다. 감사 레코드는 insights-logs-mysqlslowlogs Blob 컨테이너에 다시 JSON 형식으로 저장됩니다.

Azure Database for PostgreSQL의 서버 로그

Azure Database for PostgreSQL에서 서버 로그에는 오류 로그 및 쿼리 로그 파일이 포함됩니다. 이러한 파일의 정보를 사용하여 오류 및 비효율적인 쿼리의 원본을 찾을 수 있습니다.

다양한 log_ 서버 구성 매개 변수를 설정하여 ON 로깅을 사용하도록 설정합니다. 해당 매개 변수는 다음과 같습니다.

  • log_checkpoints. 검사점은 모든 데이터 파일이 트랜잭션 로그의 최신 정보로 업데이트 될 때마다 발생합니다. 서버 오류가 있는 경우 이 시점은 트랜잭션 로그에서 롤 포워드하여 복구를 시작해야 하는 시간을 표시합니다.
  • log_connection 및 log_disconnections. 이러한 설정은 성공한 각 연결과 각 세션의 끝을 기록합니다.
  • log_duration. 이 설정을 사용하면 완료된 각 SQL 문의 기간이 기록됩니다.
  • log_lock_waits. 이 설정으로 인해 잠금 대기 이벤트가 기록됩니다. 잠금 대기는 애플리케이션 코드에서 제대로 구현되지 않은 트랜잭션으로 인해 발생할 수 있습니다.
  • log_statement_stats. 이 설정은 서버 성능에 대한 누적 정보를 로그에 씁니다.

또한 Azure Database for PostgreSQL은 기록된 정보를 미세 조정하기 위한 추가 매개 변수를 제공합니다.

  • log_error_verbosity. 이 설정은 기록된 각 메시지에 대해 기록되는 세부 정보 수준을 지정합니다.
  • log_retention_days. 서버에서 각 로그 파일을 제거하기 전에 보존하는 일 수입니다. 기본값은 3일이며 최대 7일로 설정할 수 있습니다.
  • log_min_messages 및 log_min_error_statement. 이러한 매개 변수를 사용하여 기록 문의 경고 및 오류 수준을 지정합니다.

Azure Database for MySQL과 마찬가지로 Azure Database for PostgreSQL에서 생성된 로그 파일은 Server 로그 페이지에서 사용할 수 있습니다. 진단 설정 페이지를 사용하여 로그를 Azure Storage에 복사할 수도 있습니다.

쿼리 성능 추적

쿼리 저장소는 제대로 실행되지 않는 쿼리를 식별하고 추적하는 데 도움이 되는 Azure에서 제공하는 추가 기능입니다. Azure Database for MySQL 및 Azure Database for PostgreSQL에서 사용합니다.

쿼리 성능 추적 사용

쿼리 저장소는 Azure Database for MySQL의 mysql 스키마 및 Azure Database for PostgreSQL의 azure_sys 데이터베이스에 정보를 기록합니다. 쿼리 저장소는 쿼리 실행에 대한 데이터와 대기 통계에 대한 정보 등 두 가지 유형의 정보를 캡처할 수 있습니다. 쿼리 저장소는 기본적으로 사용하지 않도록 설정됩니다. 활성화하려면:

  • Azure Database for MySQL을 사용하는 경우 서버 매개 변수 query_store_capture_mode 설정하고 모든 query_store_wait_sampling_capture_mode.
  • Azure Database for PostgreSQL을 사용하는 경우 서버 매개 변수 pg_qs.query_capture_mode 모든 또는 TOP 설정하고 pgms_wait_sampling.query_capture_mode 매개 변수를 모든 설정합니다.

쿼리 성능 데이터 분석

쿼리 저장소에서 사용하는 테이블을 직접 쿼리할 수 있습니다. Azure Database for MySQL을 실행하는 경우 서버에 연결하고 다음 쿼리를 실행합니다.

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Azure Database for PostgreSQL을 사용하는 경우 대신 다음 쿼리를 실행합니다.

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

두 경우 모두 첫 번째 쿼리는 최근에 실행된 각 쿼리에 대한 텍스트와 쿼리가 컴파일 및 실행하는 데 걸린 기간에 대한 통계를 표시합니다. 두 번째 쿼리는 대기 이벤트에 대한 정보를 표시합니다. 대기 이벤트는 다른 쿼리가 보유한 리소스가 필요하기 때문에 한 쿼리가 실행되지 않도록 할 때 발생합니다.

쿼리 저장소를 직접 검사하는 경우 사용자 고유의 사용자 지정 보고서를 생성하고 시스템이 작동하는 방식에 대한 자세한 인사이트를 얻을 수 있습니다. 그러나 사용 가능한 데이터의 양은 무슨 일이 일어나고 있는지 이해하기 어렵게 만들 수 있습니다. Azure Database for MySQL/PostgreSQL은 쿼리 성능 인사이트쿼리 권장 사항 이 데이터를 탐색하는 데 도움이 되는 두 가지 추가 도구를 제공합니다.

Query Performance Insight 서버의 Query Performance Insight 페이지에서 사용할 수 있는 그래픽 유틸리티입니다. 장기 실행 쿼리 탭에는 가장 오래 실행되는 쿼리에 대한 통계가 표시됩니다. 기간을 지정하고 몇 분 이내에 확대합니다. 범례는 쿼리가 실행된 기간 및 횟수와 함께 각 쿼리의 텍스트를 보여 줍니다. 그래프는 각 쿼리의 기간에 대한 비교 보기를 제공합니다. 각 쿼리의 평균 시간별로 데이터를 볼 수 있지만 각 쿼리의 총 시간(기간 * 실행 횟수)을 표시하는 것도 좋습니다. 아래 이미지는 예제를 보여줍니다.

장기 실행 쿼리 탭을 보여 주는 Azure Database for PostgreSQL에 대한 Query Performance Insight 페이지의 이미지입니다.

대기 통계 탭에는 각 쿼리에 대한 대기 이벤트 정보가 표시됩니다. 쿼리에서 다양한 리소스를 기다리는 데 소요된 시간을 확인할 수 있습니다.

대기 통계 탭을 보여 주는 Azure Database for PostgreSQL에 대한 Query Performance Insight 페이지의 이미지입니다.

대기 이벤트는 일반적으로 세 가지 범주로 분류됩니다.

  • 잠금은기다립니다. 이러한 이벤트는 쿼리가 다른 쿼리에 의해 잠긴 데이터를 읽거나 수정하려고 할 때 발생합니다. 많은 수의 잠금 대기가 발생하는 경우 장기 실행 트랜잭션 또는 매우 제한적인 격리 수준을 사용하는 작업을 확인합니다.
  • IO가기다립니다. 이 유형의 대기는 쿼리가 상당한 양의 IO를 수행하는 경우에 발생합니다. 이는 잘못 디자인된 쿼리(WHERE 절 확인), 비효율적인 조인 작업 또는 누락된 인덱스로 인해 발생한 전체 테이블 검색 때문일 수 있습니다.
  • 메모리가대기합니다. 쿼리를 처리하는 데 사용할 수 있는 메모리가 부족한 경우 메모리 대기가 발생합니다. 쿼리가 많은 양의 데이터를 읽으려고 시도하거나 메모리를 호깅하는 다른 쿼리에 의해 차단될 수 있습니다. 다시 말하지만 이는 인덱스가 누락되어 쿼리가 전체 테이블을 메모리로 읽게 함을 나타낼 수 있습니다.

또한 대기의 한 형태가 다른 형식을 트리거할 가능성이 높으므로 이러한 문제를 격리된 상태로 반드시 검사할 수는 없습니다. 예를 들어 다른 테이블의 데이터를 읽고 업데이트하는 트랜잭션은 메모리 대기의 영향을 받을 수 있습니다. 따라서 이 트랜잭션은 다른 트랜잭션이 잠금 대기를 발생시키는 잠긴 데이터를 가질 수 있습니다.

서버에 대한 성능 권장 사항 페이지에서는 쿼리 저장소에 보관된 정보를 사용하여 발생하는 워크로드에 대한 데이터베이스 튜닝을 권장합니다.