MySQL 서버 로그

에러 로그

일반 쿼리 로그

바이너리 로그

슬로우 쿼리 로그

서버 로그 관리

MySQL은 여러 개의 각기 다른 로그 파일을 가지고 있는데, 이것들을 사용하면 mysqld 내부에서 진행되고 있는 것을 알아보는데 도움이 된다:

모든 로그 파일은 mysqld 데이터 디렉토리에 디폴트로 생성된다. Mysqld로 하여금 로그를 플러시 하도록 하면 강제로 로그 파일을 닫은 후에 다시 열도록 만들 수가 있다. 로그 플러싱은 FLUSH LOGS 명령문을 입력하거나, 또는 mysqladmin flush-logs 또는 mysqladmin refresh를 실행할 때 발생한다.

Section 13.5.5.2, “FLUSH 신텍스”를 참조할 것.

만약에 여러분이 MySQL 리플리케이션을 사용한다면, 슬레이브 리플리케이션 서버는 릴레이 로그 라는 로그 파일을 관리하게 된다. 이것에 대해서는 Chapter 6, “리플리케이션” 에서 다루기로 한다.

에러 로그

에러 로그 파일은 mysqld의 시작 및 종료 시점을 가리키는 정보와 서버 동작 중에 발생한 치명적인 에러에 대한 정보를 가지고 있다. 만약에 mysqld가 자동으로 검사 또는 리페어해야 할 필요가 있는 테이블을 발견하게 되면, 메시지를 에러 로그에 기록하게 된다.

어떤 OS 시스템의 경우, mysqld가 동작을 멈출 경우에 스택 트레이스 (stack trace)가 에러 로그에 기록되는 것도 있다. 이 트레이스를 사용하면 mysqld가 멈춘 곳이 어디인지를 알아볼 수가 있다.

만약에 mysqld가 예상하지 못하게 멈추었고 mysqld_safe를 사용해서 그것을 재 구동해야만 할 경우, mysqld_safe는 restarted mysqld 메시지를 에러 로그에 기록한다.

여러분은 --log-error[=file_name] 옵션을 사용해서 mysqld가 에러 로그를 저장하는 곳을 지정할 수가 있다. 만약에 아무런 file_name 값도 주지 않는다면, mysqld는 host_name.err라는 이름을 사용해서 데이터 디렉토리에 파일을 기록한다. FLUSH LOGS를 실행한다면, 에러 로그는 -old라는 접미사가 붙은 이름으로 바뀌게 되고 mysqld는 새로운 빈 로그 파일을 만든다. (--log-error 옵션을 주지 않는다면, 파일 이름 변경은 생기지 않게 된다.)

만약에 여러분이 --log-error를 지정하지 않거나, 또는 --console 옵션을 사용한다면 (윈도우에서), 에러는 표준 에러 아웃풋인 stderr에 기록된다.

윈도우에서는, -console을 주지 않으면, 에러 결과가 항상 .err 파일에 기록된다.

일반 쿼리 로그

일반 쿼리 로그는 mysqld의 일반적인 실행 결과를 기록한 것이다. 서버는 클라이언트가 접속을 하거나 또는 접속을 끊을 때 정보를 이 로그에 기록하고, 클라이언트에서 받는 각 SQL 명령문을 여기에 기록한다. 일반 쿼리 로그는 클라이언트에서 에러를 의심할 경우 및 클라이언트가 mysqld에 보내는 것이 무엇인지를 정확히 알고 싶을 때 매우 유용하게 사용된다.

mysqld는 명령문을 실행된 순서가 아닌 받는 순서대로 쿼리 로그에 기록한다.

일반 쿼리 로그를 활성화 시키기 위해서는, mysqld를 --log[=file_name] 또는 -l [file_name] 옵션과 함께 구동 시킨다. 만약에 아무런 file_name 값도 주어지지 않는다면, 디폴트 이름은 데이터 디렉토리에 있는 host_name.log가 된다.

서버 재 시작 및 로그 플러싱을 하더라도 새로운 일반 쿼리 로그 파일이 만들어지는 것은 아니다. (비록 플러싱이 로그 파일을 닫고 다시 열기는 하지만). 유닉스 시스템의 경우에는 아래의 명령어를 사용해서 이 파일을 재 명명하고 새로운 로그 파일을 만든다:

shell> mv host_name.log host_name-old.log

shell> mysqladmin flush-logs

shell> cp host_name-old.log backup-directory

shell> rm host_name-old.log

윈도우에서는, 서버가 이 로그 파일을 열어 놓은 상태에서는 이름을 바꿀 수가 없다. 여러분은 서버를 종료 시킨 다음에 이름을 바꾸어야 하고, 그런 다음에 서버를 재 시작하여 새로운 로그 파일을 만들도록 해야 한다.

바이너리 로그

바이너리 로그에는 데이터를 지금 또는 나중에 업데이트하는 모든 명령문이 기록되어 있다. 명령문은 데이터 수정을 가리키는 “이벤트 (event)” 형태로 저장된다. 바이너리 로그는 각 명령문이 데이터를 업데이트하는 소비 시간 정보도 가지고 있다.

Note: 바이너리 로그는 이전 (old)의 업데이트 로그를 대체하는 것인데, 이 엡데이트 로그는 5.0 이후부터 사용하지 않는다. 바이너리 로그는 이전의 업데이트 로그에서 사용했던 모든 정보를 보다 편리하고 트랜젝션-세이프 (transaction-safe) 형태로 가지고 있다. 만약에 여러분이 트랜젝션을 사용한다면, 반드시 업데이트 로그가 아닌 바이너리 로그를 사용해서 백업을 진행해야 한다.

바이너리 로그에는 SELECT 또는 SHOW와 같이 데이터를 수정하지 않는 명령문은 기록되지 않는다. 만약에 여러분이 모든 명령문을 로그하고 싶다면 (예를 들면, 문제 쿼리를 구분하기 위해), 일반 쿼리 로그를 사용하기 바란다.

바이너리 로그의 주요 목적은 서버가 복원 작업을 하는 동안에 가능한 한 전체적으로 데이터 베이스를 업데이트할 수 있도록 하는 것인데, 그 이유는 바이너리 로그가 백업이 만들어진 후에 발생한 모든 업데이트를 가지고 있기 때문이다. 또한, 마스터 리플리케이션 서버에서는 슬레이브 서버에 보내져야 하는 명령문을 기록하기 위해 바케이션 를 참조할 것.

바이너리 로그를 활성화 시킨 상태로 서버를 구동하면 약 1% 정도의 성능 저하가 발생한다. 하지만, 복원 작업과 리플리케이션을 설정할 수 있도록 해주는 바이너리 로그의 장점은 약간의 성능 저하 보다는 더 큰 이익을 준다.

서버를 --log-bin[=base_name] 옵션으로 시작하면, mysqld는 데이터를 업데이트하는 모든 SQL 명령어가 있는 로그 파일을 작성한다. 만약에 아무런 base_name 값도 주어지지 않는다면, 디폴트 이름은 -bin이 붙어 있는 호스트 머신 이름을 사용하게 된다. 만일 베이스 이름을 지정하기는 하였지만 절대 경로 이름 (absolute pathname) 형태가 아닌 경우에는, 서버는 파일을 데이터 디렉토리에 작성한다. 베이스 이름을 지정할 것을 권장한다.

로그 이름에 확장자를 준다고 하더라도 (예를 들면, --log-bin=base_name.extension), 그 확장자는 무시되고 제거가 된다.

mysqld는 바이너리 로그 베이스 이름에 숫자로 된 확장자를 부여한다. 그 숫자는 서버가 새로운 로그 파일을 생성할 때 마다 증가를 하기 때문에 파일의 생성 순서가 만들어 진다. 서버가 시작되거나 또는 로그를 플러시할 때 마다 서버는 새로운 바이너리 로그 파일을 생성한다. 또한, 현재의 로그 크기가 max_binlog_size에 근접할 때에도 새로운 바이너리 로그 파일을 만든다. 만약에 트랜젝션이 여러 개의 파일로 분리되지 않고 하나로 형성되기 때문에 어쩔 수 없이 큰 트랜젝션을 사용해야 하는 경우에는 바이너리 로그의 크기가 max_binlog_size 보다 커질 수는 있다.

사용된 바이너리 로그 파일을 관리하기 위해서, mysqld는 사용된 모든 바이너리 로그 파일의 이름을 가지고 있는 바이너리 로그 인덱스 파일을 생성한다. 이 인덱스 파일은 바이너리 로그 파일과 동일한 베이스 이름을 디폴트로 가지게 되며, 확장자는 '.index'가 된다. --log-bin-index[=file_name] 옵션을 사용하면 이 인덱스 파일의 이름을 변경할 수가 있다. Mysqld가 동작 중일 경우에는 수동으로 이 파일을 수정할 수가 없다; 그렇게 하면 mysqld가 혼동을 하게 된다.

바이너리 로그 파일 및 바이너리 로그 인덱스 파일 기록 방식은 MyISAM 테이블에 기록하는 방식과 동일하게 처리가 된다.

RESET MASTER 명령문을 사용하면 모든 바이너리 로그 파일을 삭제할 수 있으며, PURGE MASTER LOGS를 사용하면 로그 파일의 일부분만을 삭제할 수가 있다. Section 13.5.5.5, “RESET 신텍스”, 및 Section 13.6.1, “마스터 서버를 제어하기 위한 SQL 명령문”을 참조할 것.

바이너리 로그 포맷에는 백업에서 복원하는데 영향을 줄 수 있는 몇 가지 제약이 있다. Section 6.7, “리플리케이션 기능과 알려진 문제점들”을 참조할 것.

스토어드 루틴과 트리거에 대한 바이너리 로깅은 Section 17.4, “스토어드 루틴과 트리거에 대한 바이너리 로깅”을 참조하기 바란다.

mysqld가 바이너리 로그에 어떤 것을 기록할 때 적용할 수 있는 옵션들이 아래에 나와 있다.

만약에 여러분이 리플리케이션을 사용한다면, 여기에서 설명하는 옵션들은 마스터 서버가 자신의 슬레이브에 전달하는 명령문에 영향을 주게 된다. 마스터 서버가 보내주는 명령문을 실행 또는 무시할지를 제어하는 슬레이브 서버용 존재한다. 자세한 사항은 Section 6.8, “리플리케이션 스타트업 옵션”을 참조할 것.

• --binlog-do-db=db_name
  디폴트 데이터베이스 db_name (즉, USE가 선택한 데이터 베이스)에 대해서만 업데이트 바이너리 로깅을 진행하도록 서버에게 명령. 이름이 정확히 지정되지 않은 모든 다른 데이터 베이스는 무시된다. 이 옵션을 사용하면, 디폴트 데이터 베이스에만 업데이트를 한다는 것을 확인해야 한다. CREATE DATABASE, ALTER DATABASE, 및 DROP DATABASE 명령문에 대해서는 예외적이다. 서버는 명령문 (디폴트 데이터 베이스가 아님)안에 적혀 있는 데이터 베이스를 사용해서 명령문 기록 여부를 결정한다. 여러분이 기대한 것과는 다르게 동작하는 예를 보자: 만약에 서버가 binlog-do-db=sales 형태로 구동되고, 여러분이 USE prices; UPDATE sales.january SET amount=amount+1000;을 실행한다면, 이 명령문은 바이너리 로그에 기록이 되지 않는다. 여러 개의 데이터 베이스에 로그 하기 위해서는, 다중 옵션을 사용해서 각 데이터 베이스 별로 옵션을 지정하도록 한다.
• --binlog-ignore-db=db_name
  디폴트 데이터베이스 db_name (즉, USE가 선택한 데이터 베이스)에 대해서는 업데이트 바이너리 로깅을 하지 말도록 서버에게 명령. 이 옵션을 사용할 경우에는, 여러분이 디폴트 데이터 베이스에만 업데이트를 한다는 것을 확인해야 한다. --binlog-do-db 옵션과 마찬가지로, CREATE DATABASE, ALTER DATABASE, 및 DROP DATABASE 명령문에 대해서는 예외적이다. 서버는 명령문 (디폴트 데이터 베이스가 아님)안에 적혀 있는 데이터 베이스를 사용해서 명령문 기록 여부를 결정한다. 여러분이 기대한 것과는 다르게 동작하는 예를 보자: 만약에 서버가 binlog-do-db=sales와 함께 구동되고, 여러분이 USE prices; UPDATE sales.january SET amount=amount+1000;을 실행한다면, 이 명령문은 바이너리 로그에 기록이 된다. 여러 개의 데이터 베이스를 무시하기 위해서는, 다중옵션을 사용해서 각 데이터 베이스 별로 옵션을 지정하도록 한다.

서버는 아래의 규칙에 따라서 바이너리 로그에 업데이트를 기록 또는 무시하기 위한 옵션을 평가한다. 앞에서 설명을 하였듯이, CREATE DATABASE, ALTER DATABASE, 그리고 DROP DATABASE 명령문에 대해서는 예외적이다. 이 명령문들의 경우, 아래의 규칙에 따라 created, altered, 또는 dropped 동작을 하는 데이터 베이스가 디폴트 데이터 베이스를 대신한다.

1. --binlog-do-db 또는 --binlog-ignore-db 규칙이 있는가?
   
   • No: 바이너리 로그에 명령문을 기록한 후에 마침.
   • Yes: 다음 단계로 이동.
2. 몇 가지 규칙이 있다 (--binlog-do-db, --binlog-ignore-db, 또는 양쪽에 대해). 디폴트 데이터 베이스가 있는가 (USE에 의해 선택된 것이 있는가?)?
   
   • No: 명령문을 기록하지 않고 마침.
   • Yes: 다음 단계로 이동.
3. 디폴트 데이터 베이스가 있다. --binlog-do-db 규칙이 있는가?
   
   • Yes: 디폴트 데이터 베이스가 --binlog-do-db 규칙 중에 하나라도 일치 (match)가 되는가?
     
     • Yes: 명령문을 기록한 다음에 마침.
     • No: 명령문을 기록하지 않고 마침.
   • No: 다음 단계로 이동.
4. --binlog-ignore-db 규칙이 있다. 디폴트 데이터 베이스가 --binlog-ignore-db 규칙 중에 일치하는 것이 있는가?
   
   • Yes: 명령문을 기록하지 말고 마침.
   • No: 쿼리를 기록한 다음에 마침.

예를 들면, --binlog-do-db=sales만을 가지고 구동되는 슬레이브는 바이너리 로그 디폴트 데이터 베이스가 sales와 다른 것에 대해서는 어떠한 명령문도 바이너리 로그에 기록하지 않는다 (달리 말하면, --binlog-do-db 는 때때로 “다른 데이터 베이스는 무시”의 의미를 가지기도 한다).

리플리케이션을 사용 중에 있다면, 어떠한 슬레이브도 구형 (old) 바이너리 로그 파일을 사용하지 않는다고 확신하지 않는 한 그 바이너리 파일들을 삭제할 수가 없다. 예를 들면, 만약에 슬레이브가 3일 이상 동작하지 않았다면, 마스터에서 mysqladmin flush-logs를 실행하고 3일 이상이 된 모든 로그를 제거한다. 여러분은 수동으로 이 파일들을 삭제할 수 있겠지만, PURGE MASTER LOGS를 사용하는 것이 더욱 효과적이며, 이것을 사용하는 것이 바이너리 로그 인덱스 파일을 안전하게 업데이트 하는 방법이다. Section 13.6.1, “마스터 서버 제어를 위한 SQL 명령문”을 참조할 것.

SUPER 권한을 가지고 있는 클라이언트는 SET SQL_LOG_BIN=0 명령문을 사용해서 자신의 명령문에 대한 바이너리 로깅을 비활성화 시킬 수가 있다. Section 13.5.3, “SET 신텍스”를 참조.

여러분은 mysqlbinlog 유틸리티를 사용해서 바이너리 로그 파일의 내용을 화면에 출력 할 수 있다. 이것은 로그에 있는 명령문을 다시 실행하고자 할 때 유용하게 쓸 수 있다. 예를 들면, 아래와 같이 바이너리 로그에서 MySQL 서버를 업데이트 할 수가 있다:

shell> mysqlbinlog log_file | mysql -h server_name

Section 8.8, “mysqlbinlog - 바이너리 로그 파일 처리를 위한 유틸리티”를 참조하여 mysqlbinlog 유틸리티에 대한 정보와 사용 방법을 알아두기 바란다. mysqlbinlog를 릴레이 로그 파일과 함께 사용할 수도 있는데, 그 이유는 릴레이 로그 파일이 바이너리 로그 파일과 동일한 포맷으로 작성되어 있기 때문이다.

바이너리 로깅은 명령문이 완료된 후에 모든 잠금이 풀리거나 모든 동작이 마치기 전에 종료가 된다. 이것은 로그가 실행 순서에 따라 기록 되도록 하기 위함이다.

논-트랜젝션 (non-transactional) 테이블에 대한 업데이트는 명령문 실행 후에 즉시 바이너리 로그에 저장된다. 실행되지 않은 트랜젝션 안에서는, BDB 또는 InnoDB 테이블과 같은 트랜젝션 테이블을 변경하는 모든 업데이트 (UPDATE, DELETE, 또는 INSERT)는 COMMIT 명령문을 서버가 받을 때까지 캐시에 저장된다.. 그 시점에서, mysqld는 전체 트랜젝션을 COMMIT가 실행되기 전에 바이너리 로그에 기록한다. 트랜젝션을 처리하는 쓰레드가 시작이 되면, 쓰레드는 binlog_cache_size 버퍼를 버퍼 명령문에 할당한다. 만약에 명령문이 이것보다 크다면, 쓰레드는 트랜젝션을 저장하기 위해 임시 파일을 연다. 임시 파일은 쓰레드가 종료하면 삭제된다.

논-트랜젝션 테이블에 대한 수정은 롤백 되지 않는다. 만약에 롤백된 트랜젝션이 논-트랜젝션 테이블에 대한 수정을 포함하고 있다면, 전체 트렌젝션은 이러한 테이블에 대한 수정이 리플리케이트 되었음을 확신하기 위해 ROLLBACK 명령문을 사용해서 마지막에 기록된다.

Binlog_cache_use 상태 변수는 명령문을 저장하기 위해 이 버퍼 (또는 임시 파일)를 사용한 트랜젝션의 숫자를 표시한다. Binlog_cache_disk_use 상태 변수는 이 임시 파일을 실제로 사용한 트랜젝션의 숫자를 표시한다. 이 두 가지의 변수는 임시 파일 사용을 피하기 위한 binlog_cache_size 크기를 튜닝하는데 사용된다.

max_binlog_cache_size 시스템 변수 (디폴트 4GB)는 다중-명령문 트랜젝션을 캐시 하는데 사용되는 전체 크기를 제한하는데 사용된다. 만약에 한 트랜젝션이 이것보다 크게 되면, 그 트랜젝션은 실패하게 되고 롤백된다.

만약에 여러분이 바이너리 로그를 사용하고 있다면, 동시 삽입은 CREATE ... SELECT 또는 INSERT ... SELECT 명령문에 대한 정상 삽입으로 변환된다. 이것은 여러분이 백업 동작을 하는 도중에 로그를 적용해서 여러분의 테이블에 대한 정확한 복사본을 다시 생성할 수 있도록 하기 위해 실행되는 것이다.

5.0의 바이너리 로그 포맷은 리플리케이션의 속도를 개선하기 위해 이전의 MySQL 버전과는 달라졌다는 것을 알아두기 바란다. Section 6.5, “MySQL 버전간의 리플리케이션 호환성”을 참조.

바이너리 로그는 각각의 기록 시점에 디폴트로 디스크와 동기화 되지는 않는다. 따라서, 만약에 OS 또는 머신 (MySQL 서버뿐만 아니라)이 크래시 된다면, 바이너리 로그의 마지막 명령문을 잃을 가능성이 생긴다. 이것을 방지하기 위해서는, sync_binlog 시스템 변수를 사용해서 모든 N 이 바이너리 로그에 기록될 때마다 디스크와 동기화 하도록 해야 한다. Section 5.2.2, “서버 시스템 변수”를 참조할 것. sync_binlog을 1로 설정하는 것이 가장 안전하기는 하지만 가장 느린 값이기도 하다. sync_binlog를 1로 설정하였다고 하더라도, 크래시가 발생할 경우에는 테이블 컨텐츠와 바이너리 로그 컨텐츠 간에는 여전히 불일치가 나올 가능성이 있다. 예를 들면, 여러분이 InnoDB 테이블을 사용하고 MySQL 서버가 COMMIT 명령문을 처리 한다면, 모든 트랜젝션이 바이너리 로그에 기록되고 난 후에 이 트랜젝션을 InnoDB 안으로 넣게 된다. 만약에 서버가 이 두 개의 동작 사이에 크래시 되면, 트랜젝션은 InnoDB에 의해 롤백 되지만 여전히 바이너리 로그에 남아 있게 된다. 이 문제는 --innodb-safe-binlog 옵션으로 해결할 수 있는데, 이 옵션은 InnoDB 테이블 내용과 바이너리 로그 내용간에 일관성을 추가한다 (Note: --innodb-safe-binlog는 MySQL 5.0 이후에는 필요 없게 되었다; 이 옵션은 XA 트랜젝션 지원으로 인해 쓰지 않아도 되게 됨.)

이 옵션이 보다 완벽한 안전성을 확보하기 위해서는, MySQL 서버가 모든 트랜젝션 시점에도 바이너리 로그와 InnoDB 로그를 디스크에 동기화 되도록 구성되어야 한다. InnoDB 로그는 디폴트로 동기화 되며, sync_binlog=1는 바이너리 로그를 동기화 하기 위해 사용된다. 이 옵션은 크래시 후에 재 구동하는 시점에 트랜젝션 롤백을 한 후 MySQL 서버가 롤백된 InnoDB 트랜젝션을 바이너리 로그에서 잘라낸다. 이것은 바이너리 로그가 InnoDB 테이블의 정확한 데이터를 반영하도록 해 주기 때문에, 슬레이브는 마스터와 일관성을 유지하게 된다 (롤백된 명령문을 받지 않음).

MySQL 서버가 InnoDB가 아닌 다른 스토리지 엔진을 업데이트 할 경우에도 --innodb-safe-binlog를 사용할 수 있다는 점을 알기 바란다. InnoDB에 영향을 미치는 명령문과 트랜젝션만이 InnoDB 크래시를 복구하는 시점에 바이너리 로그에서 제거된다. 이 복구 시점에, MySQL 서버가 가지고 있어야 하는 바이너리 로그보다 짧은 것을 발견하게 되면, 성공적으로 수행된 InnoDB 트랜젝션 중에 최소한 한 개를 잃어 버린 것이다. sync_binlog=1 이고 디스크/파일시스템이 실제로 동기화를 실행한다면 이러한 일이 발생하지 않기 때문에, 서버는 binary log is shorter than its expected size. 라는 에러 메시지를 출력한다. 이와 같은 에러가 발생하는 경우에는, 바이너리 로그가 올바른 것이 아니기 때문에, 마스터 서버의 데이터 스냅 샷에서 리플리케이션을 다시 실행해야 한다.

슬로우 쿼리 로그

슬로우 쿼리 로그는 실행 시간이 long_query_time 보다 길게 걸리는 모든 SQL 명령문으로 구성된다. 초기 테이블 잠금을 얻기 위한 시간은 실행 시간으로 계산되지 않는다. long_query_time의 최소값 및 디폴트 값은 각각 1 과 10이다.

mysqld는 명령문을 실행한 후 그리고 모든 잠금이 풀린 후에 그 명령문을 슬로우 쿼리 로그에 기록한다. 기록 순서는 실행 순서와는 다르다.

슬로우 쿼리 로그를 활성화 시키기 위해서는, mysqld를 --log-slow-queries[=file_name] 옵션과 함께 시작한다.

아무런 file_name 값도 지정하지 않는다면, 디폴트는 -slow.log의 접미사를 가지고 있는 호스트 머신의 이름을 사용한다. 만약에 파일 이름은 지정하였으나 절대 경로 이름이 아니라면, 서버는 파일을 데이터 디렉토리에 기록한다.

슬로우 쿼리 로그는 실행 시간이 오래 걸리는 쿼리를 찾아서 최적화 하고자 할 때 사용할 수 있다. 하지만, 긴 슬로우 쿼리 로그를 검사 하는 것은 어려운 작업이다. 이 작업을 보다 쉽게 하기 위해서는, 로그안에 있는 쿼리를 요약하는 mysqldumpslow 명령어를 사용해서 슬로우 쿼리를 처리 하도록 한다. mysqldumpslow -help를 사용해서 이 명령어에 사용할 수 있는 옵션들을 보도록 한다.

MySQL 5.0에서, 인덱스를 사용하지 않는 슬로우 쿼리는 인덱스를 사용하는 쿼리와 함께 기록된다. 슬로우 쿼리 로그에 인덱스를 사용하지 않는 쿼리가 기록되는 것을 방지하기 위해서는, --log-queries-not-using-indexes 옵션을 사용한다. Section 5.2.1, “mysqld 명령어 옵션”을 참조.

MySQL 5.0에서, --log-slow-admin-statements 서버 옵션은 OPTIMIZE TABLE, ANALYZE TABLE, 그리고 ALTER TABLE 과 같은 관리 명령문을 슬로우 쿼리 로그에 기록할 수 있도록 한다.

쿼리 캐시가 처리하는 쿼리들은 슬로우 쿼리 로그에 추가되지 않으며, 테이블에 열이 없거나 하나의 열만 가지고 있기 때문에 인덱스를 사용할 필요가 없는 쿼리들도 슬로우 쿼리 로그에 추가되지 않는다.

서버 로그 관리

MySQL 서버는 서로 다른 여러 개의 로그 파일을 생성해서 현재 진행되고 있는 것을 보다 쉽게 볼 수 있도록 할 수 있다. 하지만, 이러한 로그들이 너무 많은 디스크 공간을 차지하지 못하도록 정기적으로 삭제하도록 한다.

MySQL 을 로깅 활성화 상태로 사용할 때에는, 백업을 받고 오래된 로그 파일을 때때로 삭제할 필요가 있으며 MySQL이 새로운 파일에 로깅 하도록 만들 수 있다.

리눅스 (레드 헷)에 설치하는 경우에는 mysql-log-rotate 스크립트를 사용해서 위의 동작을 실행할 수가 있다. RPM 버전을 가지고 MySQL을 설치 한다면, 이 스크립트는 자동으로 설치가 된다. 리플리케이션을 위해 바이너리 로그를 사용하는 중이라면, 이 스크립트를 사용하는 것에 주의 하도록 한다. 바이너리 로그에 있는 내용을 모든 슬레이브가 처리했다고 확신할 때까지는 바이너리 로그를 삭제할 수가 없다.

다른 시스템의 경우에는 스스로 간단한 스크립트를 설치해서 서버가 cron (또는 동일한 것들)에서 시작을 할 수 있도록 해야 한다.

mysqladmin flush-logs를 사용하거나 또는 SQL 명령문인 FLUSH LOGS를 사용해서 MySQL 서버가 새로운 로그 파일을 사용해서 구동 하도록 만들 수가 있다.

로그 플러싱 연산은 다음과 같이 진행된다:

• 일반 쿼리 로깅 (--log) 또는 슬로우 쿼리 로깅 (--log-slow-queries)을 사용 한다면, 서버는 일반 쿼리 로그 파일과 슬로우 쿼리 로그 파일을 닫은 다음에 다시 연다.
• 바이너리 로깅 (--log-bin)을 사용하면, 서버는 현재의 로그 파일을 닫고 그 다음 번호를 사용해서 새로운 로그 파일을 연다.

서버는 로그를 플러시할 때 새로운 바이너리 로그 파일을 생성한다. 하지만, 서버는 일반 쿼리 로그 파일과 슬로우 쿼리 로그 파일은 단순히 닫은 다음에 다시 열기만 한다. 유닉스에서 새로운 파일이 생성되도록 하기 위해서는, 현재의 로그를 플러시 하기 전에 이름을 바꿔 준다. 플러시를 할 때에는, 서버는 원래의 이름을 사용해서 새로운 로그를 열게 된다. 예를 들면, 만약에 일반 쿼리 로그와 슬로우 쿼리 로그가 mysql.log 와 mysql-slow.log라고 되어 있다면, 아래와 같은 일련의 명령어를 사용할 수가 있다:

shell> cd mysql-data-directory

shell> mv mysql.log mysql.old

shell> mv mysql-slow.log mysql-slow.old

shell> mysqladmin flush-logs

이 시점에, mysql.old 와 mysql-slow.log의 백업을 만들고 난 후에 디스크에서 그것들을 삭제한다.

윈도우 시스템의 경우, 서버가 로그 파일을 오픈한 동안에는 이름을 바꾸지 못한다. 반드시 서버를 멈춘 후에 파일 이름을 바꾸고, 서버를 재 구동 시켜서 새로운 파일을 만들도록 해야 한다.