: 로그 파일을 사용하면 MySQL 서버의 깊은 내부 지식이 없어도 MySQL의 상태나 부하를 일으키는 원인을 쉽게 찾아서 해결할 수 있음
: MySQL 서버에 문제가 생겼을 때는 로그 파일을 확인하는 습관을 가져라!
1. 에러 로그 파일
: 실행도중 발생하는 에러나 경고 메시지가 출력되는 로그 파일, my.cnf에서 log_error라는 이름의 파라미터로 정의된 경로에 생성
1.
MySQL이 시작하는 과정과 관련된 정보성 및 에러 메시지
: MySQL 서버가 정상적으로 기동(’mysqld: ready for connections’), 새로 변경하거나 추가한 파라미터에 대한 에러나 경고성 메시지가 없다면 정상적으로 적용된 것
: 아니라면.. ignore 되었따면.. 에러 메시지를 출력하고 시작하지 못했다는 메시지를 출력할 것.
2.
마지막으로 종료할 때 비정상적으로 종료된 경우 나타나는 InnoDB의 트랜잭션 복구 메시지
: 이 경우, 리두 로그나, 언두 로그를 까서 복구 작업을 할텐데, 이에 대한 메시지를 출력함, 근데 복구 작업에서 오류가 생기면..? 해당 에러 메시지를 출력하고 다시 종료..
: innodb_force_recovery 파라미터를 건드려야할 수도 있다.. 덜덜
3.
쿼리 처리 도중에 발생하는 문제에 대한 에러 메시지
: 쿼리 도중 발생하는 문제점은 사전 예방이 어렵다. 주기적으로 에러 로그 파일을 검토하는 과정에서 알게 되는데 쿼리 실행 도중 발생한 에러나 복제에서 문제가 될 만한 쿼리에
대한 경고 메시지가 에러 로그에 기록 됨
: 자주 에러 로그 파일을 검토하는 것이 좋다..
4.
비정상적으로 종료된 커넥션 메시지
: 클라이언트 애플리케이션이 정상적으로 접속 종료하지 못하고 프로그램이 종료된 경우, 해당 메시지가 자주 기록된다면 커넥션 종료 로직을 검토해볼 필요가 있음
방금 로그 보고 오니 진짜 쌓여 있네?
으악 망했다
5.
InnoDB의 모니터링 또는 상태 조회 명령의 결과 메시지
: InnoDB의 테이블 모니터링이나 락 모니터링 또는 InnoDB의 엔진 상태를 조회하는 명령은 상대적으로 큰 메시지를 에러 로그 파일에 기록
: InnoDB의 모니터링을 활성화 상태로 만들어 두고 그대로 유지하는 경우에는 에러 로그 파일이 매우 커지므로 주기적으로 삭제해주자
6.
MySQL의 종료 메시지
: 가끔 MySQL이 아무도 모르게 종료되어있거나 아무도 모르게 재시작되는 경우, 에러 로그 파일에 종료되면서 출력한 메시지가 기록됨
: 만약 누군가가 종료시키면 Received SHUTDOWN from user…, 그렇지 않다면 스택 트레이스와 같은 내용들이 출력될 텐데, 이는 MySQL 서버가 세그먼테이션 폴트로 강제 종료
된 것으로 유추할 수 있음, 이 경우 스택 트레이스의 내용을 최대한 참조해서 MySQL의 버그와 연관이 있는지 조사한 후 MySQL 버전을 업그레이드하거나 적절한 회피책을
찾는 것이 최적의 방법..
에러 로그에 대한 자세한 정보는 MySQL 메뉴얼의 ‘The Error Log’를 읽어보자
2. 제너럴 쿼리 로그 파일(제너럴 로그 파일, General log)
: MySQL 서버에서 실행되는 쿼리가 무엇이 있는지 확인하고 싶을때, 쿼리 로그를 활성화해서 쿼리를 쿼리 로그 파일로 기록하게 한 다음 해당 파일을 검토하면 됨
: 쿼리 로그 파일에는 시간 단위로 실행됐던 쿼리의 내용이 모두 기록됨, 슬로우 쿼리 로그와는 다른 것이 제너럴 쿼리 로그는 MySQL이 요청을 받으면 바로 기록하기 때문에
실행 완료 여부와 관련없이 기록된다.
: 쿼리 로그 파일의 경우는 general_log_file이라는 이름의 파라미터에 설정되어있다. 또한 쿼리 로그를 테이블에 저장하도록 설정할 수 있음
: 이는 log_output 파라미터로 결정할 수 있는데, 제너럴 로그와 관련된 상세한 내용은 MySQL 메뉴얼의 log_output 설정 파라미터와 The General Query Log를 참조
: 로그 파일의 경로에 관련된 상세한 내용은 MySQL 메뉴얼의 “Selecting General Query and Slow Query Log Output Destinations”를 참조
3. 슬로우 쿼리 로그
: MySQL 서버의 쿼리 튜닝의 경우
•
서비스가 적용되기 전에 전체적으로 튜닝하는 경우
•
서비스 운영 중에 MySQL 서버의 전체적인 성능을 검사하거나 정기적인 점검을 위한 튜닝
: 전자의 경우 검토해야할 대상 쿼리가 전부라서 모두 튜닝하면 되지만 후자의 경우 어떤 쿼리가 문제의 쿼리인지 판단하기가 힘들다. 이런 경우 슬로우 쿼리 로그가 도움
: 슬로우 쿼리 로그 파일에는 long_query_time 시스템 변수에 설정한 시간 이상의 시간이 소요된 쿼리가 모두 기록, 반드시 쿼리가 실행이 완료되어야 기록됨
: 슬로우 쿼리 로그 또한 log_output 옵션을 이용해 파일로 기록할지 테이블로 기록할지 선택할 수 있다.
•
슬로우 쿼리 로그 설명
◦
Time
▪
쿼리가 실행된 시간이 아닌 쿼리가 종료된 시점을 의미, 시작 시점은 Time 항목 - Query_time
◦
User@Host
▪
쿼리를 실행한 사용자의 계정
◦
Query_time
▪
쿼리가 실행되는 데 걸린 전체 시간, Lock_time의 경우 MySQL 엔진 레벨에서 관장하는 테이블 잠금에 대한 대시 시간, 이 값이 매우 작으면 무시해도 무방
◦
Rows_examined, Rows_sent
▪
이 쿼리가 처리되기 위해 몇 건의 레코드에 접근했는지를 의미하며 Rows_sent는 실제 몇 건의 처리 결과를 클라이언트로 보냈는지를 의미
▪
examined의 레코드 건수가 높고 sent의 레코드 건수가 상당히 적다면 이 쿼리는 조금 더 적은 레코드만 접근하도록 튜닝해볼 가치가 있다.
: 일반적으로 슬로우 쿼리 또는 제너럴 로그 파일의 내용이 상당히 많아서 직접 쿼리를 하나씩 검토하기에는 힘들 경우, Percona에서 개발한 Percona Toolkit의
pt-query-digest 스크립트를 이용하면 쉽게 빈도나 처리 성능별로 쿼리를 정렬해서 살펴볼 수 있다.
: 로그 파일의 분석이 완료되면 그 결과는 다음과 같이 3개의 그룹으로 나뉘어 저장
1.
슬로우 쿼리 통계
: 분석 결과의 최상단에 표시되며 모든 쿼리를 대상으로 슬로우 쿼리 로그의 실행 시간, 잠금 대기 시간 등에 대해 평균 및 최소/최대 값을 표시
2.
실행 빈도 및 누적 실행 시간순 랭킹
: 각 쿼리 별로 응답 시간과 실행 횟수, pt-query-digest 명령 실행 시 —order-by 옵션으로 순서를 변경할 수 있음
3.
쿼리별 실행 횟수 및 누적 실행 시간 상세 정보
: Query ID별 쿼리를 쿼리 랭킹에 표시된 순서대로 자세한 내용을 보여줌
