7.4.6 Server Log Maintenance

7.4.6 Server Log Maintenance

Section 7.4, “MySQL Server Logs”에서 설명한 것처럼, MySQL Server는 어떤 활동이 일어나고 있는지 확인하는 데 도움이 되도록 여러 가지 서로 다른 로그 파일을 생성할 수 있습니다. 하지만 로그가 너무 많은 디스크 공간을 차지하지 않도록 하기 위해서는 이러한 파일을 정기적으로 정리해야 합니다.

로깅을 활성화한 상태에서 MySQL을 사용할 때는 때때로 예전 로그 파일을 백업한 후 제거하고, MySQL에게 새로운 파일에 로깅을 시작하라고 지시하고 싶을 수 있습니다. Section 9.2, “Database Backup Methods”를 참조하십시오.

Linux (Red Hat) 설치에서는 로그 유지 관리를 위해 mysql-log-rotate 스크립트를 사용할 수 있습니다. RPM 배포판으로 MySQL을 설치했다면, 이 스크립트는 자동으로 설치되었어야 합니다. 복제를 위해 바이너리 로그를 사용하는 경우 이 스크립트를 사용할 때는 주의해야 합니다. 모든 레플리카가 그 내용을 처리했다는 것이 확실해질 때까지는 바이너리 로그를 제거해서는 안 됩니다.

다른 시스템에서는 로그 파일을 처리하기 위해 cron(또는 이와 동등한 것)에서 시작하는 짧은 스크립트를 직접 설치해야 합니다.

바이너리 로그 파일은 서버의 바이너리 로그 만료 기간이 지나면 자동으로 제거됩니다. 파일 제거는 시작 시점과 바이너리 로그가 플러시될 때 발생할 수 있습니다. 기본 바이너리 로그 만료 기간은 30일입니다. 다른 만료 기간을 지정하려면 binlog_expire_logs_seconds 시스템 변수를 사용하십시오. 복제를 사용하는 경우, 레플리카가 소스보다 뒤처질 수 있는 최대 시간보다 작지 않은 만료 기간을 지정해야 합니다.

필요 시점에 바이너리 로그를 제거하려면 PURGE BINARY LOGS 스테이트먼트를 사용하십시오(Section 15.4.1.1, “PURGE BINARY LOGS Statement” 참조).

MySQL이 새로운 로그 파일을 사용하도록 강제로 전환하려면 로그를 플러시하십시오. 로그 플러싱은 FLUSH LOGS 스테이트먼트나 mysqladmin flush-logs, mysqladmin refresh, mysqldump --flush-logs, 또는 mysqldump --source-data 커맨드를 실행할 때 발생합니다.

Section 15.7.8.3, “FLUSH Statement”, Section 6.5.2, “mysqladmin — A MySQL Server Administration Program”, 그리고 Section 6.5.4, “mysqldump — A Database Backup Program”를 참조하십시오.

추가로, 서버는 현재 바이너리 로그 파일 크기가 max_binlog_size 시스템 변수 값에 도달하면 자동으로 바이너리 로그를 플러시합니다.

FLUSH LOGS는 개별 로그를 선택적으로 플러시할 수 있도록 하는 선택적 수정자를 지원합니다(예를 들어, FLUSH BINARY LOGS). Section 15.7.8.3, “FLUSH Statement”를 참조하십시오.

로그 플러싱 작업은 다음과 같은 효과를 갖습니다:

• 바이너리 로깅이 활성화된 경우, 서버는 현재 바이너리 로그 파일을 닫고 다음 시퀀스 번호를 가진 새로운 로그 파일을 엽니다.

• 로그 파일로의 일반 쿼리 로깅 또는 느린 쿼리 로깅이 활성화된 경우, 서버는 로그 파일을 닫았다가 다시 엽니다.

• 서버가 에러 로그가 파일에 쓰이도록 --log-error 옵션과 함께 시작된 경우, 서버는 로그 파일을 닫았다가 다시 엽니다.

로그 플러싱 스테이트먼트 또는 커맨드를 실행하려면 RELOAD 권한을 가진 계정을 사용하여 서버에 연결해야 합니다. Unix 및 Unix 계열 시스템에서는 또 다른 방법으로 서버에 시그널을 보내어 로그를 플러시할 수 있으며, 이는 root 또는 서버 프로세스 소유 계정이 수행할 수 있습니다(Section 6.10, “Unix Signal Handling in MySQL” 참조). 시그널을 사용하면 서버에 연결하지 않고도 로그 플러싱을 수행할 수 있습니다:

• SIGHUP 시그널은 모든 로그를 플러시합니다. 하지만 SIGHUP은 로그 플러싱 이외에 바람직하지 않을 수 있는 추가 효과를 갖습니다.

• SIGUSR1은 서버로 하여금 에러 로그, 일반 쿼리 로그, 느린 쿼리 로그를 플러시하게 합니다. 해당 로그만 플러시하는 데 관심이 있다면, 로그와 관련 없는 SIGHUP 효과를 갖지 않는 보다 “lightweight”한 시그널로 SIGUSR1을 사용할 수 있습니다.

앞서 언급했듯이, 바이너리 로그를 플러시하면 새로운 바이너리 로그 파일이 생성되는 반면, 일반 쿼리 로그, 느린 쿼리 로그, 에러 로그를 플러시하면 단지 로그 파일을 닫았다가 다시 열 뿐입니다. 후자의 로그에 대해서 Unix에서 새로운 로그 파일이 생성되도록 하려면, 플러시하기 전에 먼저 현재 로그 파일의 이름을 변경하십시오. 플러시 시점에 서버는 원래 이름으로 된 새로운 로그 파일을 엽니다.

예를 들어, 일반 쿼리 로그, 느린 쿼리 로그, 에러 로그 파일 이름이 각각 mysql.log, mysql-slow.log, err.log라면, 커맨드 라인에서 다음과 같은 일련의 커맨드를 사용할 수 있습니다:

1cd mysql-data-directory
2mv mysql.log mysql.log.old
3mv mysql-slow.log mysql-slow.log.old
4mv err.log err.log.old
5mysqladmin flush-logs

Windows에서는 mv 대신 rename을 사용하십시오.

이 시점에서 mysql.log.old, mysql-slow.log.old, err.log.old의 백업을 수행한 후, 디스크에서 제거할 수 있습니다.

런타임에 일반 쿼리 로그 또는 느린 쿼리 로그의 이름을 변경하려면, 먼저 서버에 연결한 뒤 로그를 비활성화하십시오:

1SET GLOBAL general_log = 'OFF';
2SET GLOBAL slow_query_log = 'OFF';

로그가 비활성화된 상태에서 로그 파일의 이름을 외부에서 변경하십시오(예: 커맨드 라인에서). 그런 다음 로그를 다시 활성화합니다:

1SET GLOBAL general_log = 'ON';
2SET GLOBAL slow_query_log = 'ON';

이 방법은 어떤 플랫폼에서도 동작하며 서버 재시작을 요구하지 않습니다.

참고

외부에서 파일 이름을 변경한 후 서버가 특정 로그 파일을 다시 생성하도록 하려면, 해당 파일 위치는 서버가 쓰기 가능해야 합니다. 이는 항상 그런 것은 아닙니다. 예를 들어, Linux에서는 서버가 에러 로그를 /var/log/mysqld.log로 쓸 수 있고, /var/log는 root가 소유하며 mysqld가 쓰기 할 수 없을 수 있습니다. 이 경우, 로그 플러싱 작업은 새로운 로그 파일을 생성하는 데 실패합니다.

이 상황을 처리하려면, 원래 로그 파일의 이름을 변경한 후 올바른 소유권으로 새로운 로그 파일을 수동으로 생성해야 합니다. 예를 들어, root로 다음 커맨드를 실행하십시오:

1mv /var/log/mysqld.log /var/log/mysqld.log.old
2install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log