linuxism

에러 로그 파일에는,mysqld 의 기동 시각과 정?~ 시각, 및 실행중에 발생한 에러에 관한 정보가 기록됩니다.

mysqld 하지만 이상종료(ABEND) 해 mysqld_safe 하지만 mysqld (을)를 재기동할 필요가 있는 경우,mysqld_safe (은)는 이 파일에 restarted mysqld 행을 씁니다.자동 체크 또는 자동 수복이 필요한 테이블을 mysqld 하지만 찾아냈을 경우, 경고도 기록됩니다.

일부의 operating system에서는,mysqld 하지만 이상종료(ABEND) 한 개소의 스택 트레이스가 에러 로그에 기록됩니다.이것을 사용하면,mysqld 하지만 어느 시점에서 이상종료(ABEND) 했는지 압니다. See 항E.1.4. 「스택 트레이스의 사용」 .

MySQL 4.0.10 이?~ ,mysqld 하지만 에러 로그 파일을 보존하는 장소를 --log-error[=filename] 옵션으로 지정할 수 있게 되어 있습니다.파일명을 지정하지 않으면,mysqld 하 Unix 그럼 mysql-data-dir/'hostname'.err (을)를,Windows 그럼 \mysql\data\mysql.err (을)를 사용합니다. flush logs (을)를 실행하면, 낡은 파일에는 --old 의 프리픽스가 붙어,mysqld 하지만 하늘의 신규 로그 파일을 작성합니다.

구 MySQL 버젼에서는, 에러 로그 처리는 mysqld_safe 에 의해서 행해져 에러 파일은 'hostname'.err 에 리디렉트 됩니다.이 파일명은,--err-log=filename 옵션으로 변경할 수 있습니다.

--log-error (을)를 지정하지 않는 경우, 또는 --console 옵션을 사용했을 경우에는, 에러는 stderr (단말)에 써집니다.

Windows 그럼,--console (을)를 지정하지 않으면, 출력은 항상 .err 파일에 써집니다.

mysqld 안에서 무엇이 발생하고 있을까 확인하고 싶은 경우에는,--log[=file] 옵션을 사용해 mysqld (을)를 기동합니다.이것에 의해, 모든 접속과 쿼리가 로그 파일(디폴트는 'hostname'.log )에 기록됩니다.이 로그는, 클라이언트 측에 에러의 원인이 있다고 생각할 수 있어mysqld 에 대해서 클라이언트가 무엇을 송신했는지 조사할 때 매우 도움이 됩니다.

낡은 버젼(MySQL 3.23.4 (으)로부터 3.23.8 )의 mysql.server 스크립트는,safe_mysqld 에, 일반 쿼리 로그를 유효화한다 --log 옵션을 건네줍니다.실가동 환경에서 MySQL 의 기동시의 퍼포먼스를 향상시킬 필요가 있는 경우에는,--log 옵션을 mysql.server (으)로부터 삭제하는지,--log-bin (으)로 변경합니다. See 항4.10.4. 「바이너리 로그」 .

이 로그의 엔트리는,mysqld 하지만 쿼리를 받은 시점에서 써집니다.이것은, 스테이트먼트가 실행된 순서와는 다른 경우가 있습니다.또, 갱신 로그 및 바이너리 로그와도 대비적입니다.갱신 로그 및 바이너리 로그는, 쿼리가 실행된 후, 락이 해제되기 전에 써집니다.

주의: 갱신 로그는 폐?~ 되어 대신에 바이너리 로그가 사용됩니다.See 항4.10.4. 「바이너리 로그」 . 바이너리 로그는, 이전의 갱신 로그의 기능을 모두 갖추어 더해 다른 기능도 추가되고 있습니다.MySQL 5.0 그리고 갱신 로그는 없어집니다 .

mysqld (을)를 --log-update[=file_name] 옵션으로 기동하면, 데이터를 갱신하는 모든 SQL 커멘드가 로그 파일에 기록됩니다.파일명을 지정하지 않으면, 호스트 머신의 이름이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하지 않는 경우, 파일은 데이터 디렉토리에 작성됩니다.file_name 에 확장자(extension)가 없는 경우,mysqld 하file_name.### 의 형식에서 로그 파일명을 생성합니다.여기서 ### (은)는,mysqladmin refresh ,mysqladmin flush-logs , 및 FLUSH LOGS 스테이트먼트가 실행될 때마다, 및 서버가 재기동할 때마다 인크리먼트(increment) 되는 번호입니다.

주의: 상기 스킴이 유효하기 때문에 , 갱신 로그가 사용하는 디렉토리내에서는, 갱신 로그 + 어떠한 확장자(extension) 등, 번호라고 오인되는 파일명의 파일을 작성 해서는 안됩니다.

--log 옵션 또는 -l 옵션을 사용했을 경우,mysqld 하 hostname.log (이)라는 이름의 일반 로그 파일을 작성합니다.재기동이나 리프레쉬를 실시해도 신규 로그 파일은 생성되지 않습니다(일단 닫고, 재차 열 뿐입니다).이 경우, 이하와 같이 해(Unix 상) 로그 파일을 카피할 수 있습니다.

mv hostname.log hostname-old.log
mysqladmin flush-logs
cp hostname-old.log to-backup-directory
rm hostname-old.log

갱신 로그는, 데이터를 실제로 갱신한 스테이트먼트만을 기록합니다.UPDATE 또는 DELETE 의 WHERE 지정으로 레코드가 발견되지 않았던 경우, 그 스테이트먼트는 로그에 써지지 않습니다.컬럼의 값을, 벌써 있는 같은 값으로 갱신했다 UPDATE 스테이트먼트도 스킵 됩니다.

갱신 로그의 기입은, 쿼리가 완료한 직후에 락의 해제전에, 또는 코?~ 트의 전에 행해집니다.이 때문에, 로그는 실행 순서대로 써집니다.

갱신 로그 파일로부터 데이타베이스를 갱신하려면 , 이하를 실행합니다.여기에서는, 갱신 로그명의 형식을 file_name.### (와)과 가정하고 있습니다.

shell> ls -1 -t -r file_name.[0-9]* | xargs cat | mysql

ls (은)는, 모든 로그 파일을 올바른 순서로 취득하기 위해서 사용합니다.

이것은, 크래쉬 후에 백업파일 상태에까지 되돌린다, 혹은 백업 후부터 크래쉬까지의 사이의 갱신을 반복하는 경우 등에 도움이 됩니다.

바이너리 로그는, 이전의 갱신 로그 대신에 되는 것입니다.갱신 로그는 MySQL 5.0 (이)가 아니게 됩니다.바이너리 로그에는, 갱신 로그로 이용 가능했던 정보가 모두, 보다 효율적 한편 트랜잭션(transaction) 세이프인 방법으로 포함됩니다.

바이너리 로그는 이전의 갱신 로그와 같이, 데이터를 실제로 갱신하는 스테이트먼트만을 기록합니다.UPDATE 또는 DELETE 의 WHERE 지정으로 레코드가 발견되지 않았던 경우, 그 스테이트먼트는 로그에 써지지 않습니다.컬럼의 값을, 벌써 있는 같은 값으로 갱신했다 UPDATE 스테이트먼트도 스킵 됩니다.

바이너리 로그에는, 백업 후의 갱신이 모두 기록됩니다.바이너리 로그의 주된 목적은, restore시에, 데이타베이스에 대해서 가능한 한 백업 후의 갱신을 실행할 수 있도록 하는 것입니다.

바이너리 로그는, 마스터로부터 슬레이브에 replication를 실시할 때도 사용합니다. See 항4.11. 「MySQL 의 replication」 .

바이너리 로그에는, 데이타베이스를 갱신한 각 쿼리에 걸린 시간의 정보도 포함됩니다.데이터를 변경하지 않았던 쿼리는 포함되지 않습니다.문제가 있는 쿼리를 찾아내는 등의 목적으로 모든 쿼리를 기록하고 싶은 경우에는, 일반 쿼리 로그를 사용해 주세요. See 항4.10.2. 「일반 쿼리 로그」 .

mysqld (을)를 --log-bin[=file_name] 옵션으로 기동하면, 데이터를 갱신한 모든 SQL 커멘드가 로그 파일에 기록됩니다.파일명을 지정하지 않으면, 호스트 머신의 이름에 -bin (을)를 붙인 것이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하고 있지 않는 경우에는, 파일은 데이터 디렉토리에 작성됩니다.

--log-bin=filename.extension 그리고 확장자(extension)를 지정했을 경우, 확장자(extension)는 삭제됩니다.

mysqld (은)는, 바이너리 로그 파일명에 숫자의 확장자(extension)를 추가합니다.이 번호는,mysqladmin refresh ,mysqladmin flush-logs , 및 FLUSH LOGS 스테이트먼트가 실행될 때마다, 또는 서버가 재기동할 때마다 인크리먼트(increment) 됩니다.바이너리 로그의 사이즈가 max_binlog_size 에 이르면, 새로운 바이너리 로그가 자동적으로 작성됩니다.주의: 트랜잭션(transaction)를 사용하고 있는 경우, 트랜잭션(transaction)는 1 개의 정리로 바이너리 로그에 써지기 위해, 복수의 바이너리 로그에 분할될 것은 없습니다.따라서, 큰 트랜잭션(transaction)가 있는 경우, 바이너리 로그가 max_binlog_size 보다 커질 가능성이 있습니다.

모든 바이너리 로그 파일을 삭제하려면 ,RESET MASTER 커멘드(see 항4.6.5. 「RESET 구문」 )(을)를 사용합니다.일부의 파일을 삭제하려면 ,PURGE MASTER LOGS (see항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 )(을)를 사용합니다.

mysqld 그리고 이하의 옵션을 사용해, 무엇을 바이너리 로그에 기록할까 제어할 수 있습니다(겉(표)의 뒤의 설명을 반드시 읽어 주세요).

쿼리를 바이너리 로그에 쓸지의 평가는, 이하의 순서로 행해집니다.

따라서, 예를 들어 binlog-do-db=sales 만으로 실행중의 슬레이브는, 경향 데이타베이스가 sales (이)가 아닌 쿼리를 일절 바이너리 로그에 쓰지 않습니다(즉,binlog-do-db 하 `` 다른 데이타베이스를 무시한다'' 그렇다고 하게도 됩니다).

어느 바이너리 로그 파일이 사용되었는지 알도록(듯이),mysqld (은)는 바이너리 로그인 덱스 파일도 작성합니다.이 파일에, 사용된 바이너리 로그 파일 모든 이름이 포함됩니다.디폴트에서는, 이 파일의 이름은 바이너리 로그 파일명에 확장자(extension) '.index' (을)를 붙인 것이 됩니다. 바이너리 로그인 덱스 파일의 이름을 변경하려면 ,--log-bin-index=[filename] 옵션을 사용합니다. mysqld 의 실행중은, 이 파일을 수동으로 편집하지 말아 주세요.mysqld 하지만 혼란하는 원인이 됩니다.

replication를 사용하고 있는 경우, 슬레이브가 필요로 하고 있는 동안은, 낡은 바이너리 로그 파일을 삭제하지 말아 주세요. 예를 들어,mysqladmin flush-logs (을)를 매일 실행하는 경우,3 일 경과한 로그를 모두 삭제하도록(듯이) 합니다.이러한 로그는 수동으로 삭제할 수도 있습니다만, 바이너리 로그인 덱스 파일도 안전하게 갱신할 수 있다 PURGE MASTER LOGS (see 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 )(을)를 사용해 삭제하는 것을 추천 합니다.이 커멘드는,MySQL 4.1 (으)로부터 일자 인수를 지정할 수 있게 되어 있습니다.

SUPER 권한으로의 접속에서는,SET SQL_LOG_BIN=0 (을)를 사용하고, 쿼리의 바이너리 로그를 무효로 할 수 있습니다. See 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 .

바이너리 로그 파일을 조사하려면 ,mysqlbinlog 유틸리티를 사용합니다. 예를 들어, 이하와 같이 바이너리 로그로부터 MySQL 서버를 갱신할 수 있습니다.

shell> mysqlbinlog log-file | mysql -h server_name

mysqlbinlog 유틸리티 및 그 사용법에 관한 상세한 것에 대하여는, 항4.9.5. 「mysqlbinlog (바이너리 로그로부터 쿼리를 실행한다)」 (을)를 참조해 주세요.

BEGIN [WORK] 또는 SET AUTOCOMMIT=0 (을)를 사용하고 있는 경우는, 이전의 갱신 로그는 아니고 MySQL 바이너리 로그를 백업용으로 사용해 주세요.갱신 로그는 MySQL 5.0 (이)가 아니게 됩니다.

바이너리 로그의 기입은, 쿼리가 완료한 직후에 락의 해제전에, 또는 코?~ 트의 전에 행해집니다.이 때문에, 로그는 실행 순서대로 써집니다.

비트랜잭션(transaction) 테이블의 갱신은 실행 직후에 바이너리 로그에 보존됩니다.BDB 테이블이나 InnoDB 테이블등의 트랜잭션(transaction) 테이블에서는, 테이블을 변경하는 모든 갱신(UPDATE ,DELETE , 또는 INSERT )(은)는,COMMIT 커멘드가 서버에 송신될 때까지 캐쉬됩니다.mysqld (은)는,COMMIT 하지만 실행되기 전에 트랜잭션(transaction) 전체를 바이너리 로그에 씁니다. 모든 스레드가, 최초로, 쿼리를 버퍼 한다 binlog_cache_size 의 버퍼를 할당합니다.쿼리가 이것보다 큰 경우, 스레드는 임시 파일을 열어 트랜잭션(transaction)를 보존합니다.스레드가 종료하면 임시 파일은 삭제됩니다.

max_binlog_cache_size (디폴트는 4G )(을)를 사용하고, 복수 쿼리 트랜잭션(transaction)의 캐쉬에 사용하는 토탈 사이즈를 제한할 수 있습니다.트랜잭션(transaction)가 이것보다 큰 경우, 에러가 되어 롤백(rollback) 합니다.

갱신 로그 또는 바이너리 로그를 사용하고 있는 경우에,CREATE ... SELECT 또는 INSERT ... SELECT (을)를 사용하면, 동시 삽입이 통상의 삽입에 변환됩니다. 이것은, 백업에 로그를 적용했을 때에, 테이블의 정확한 카피를 작성하기 위한 조치입니다.

mysqld (을)를 --log-slow-queries[=file_name] 옵션으로 기동하면, 실행에 long_query_time 초보다 길게 걸렸다 SQL 커멘드가 모두 로그 파일에 써집니다.최초의 테이블 락에 걸린 시간은 실행 시간에 포함되지 않습니다.

슬로우 쿼리 로그는, 쿼리 실행 후, 모든 락이 해제된 후에 써집니다.이것은, 스테이트먼트가 실행된 순서와는 다른 경우가 있습니다.

파일명을 지정하지 않으면, 호스트 머신의 이름에 -slow.log (을)를 붙인 것이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하지 않는 경우, 파일은 데이터 디렉토리에 작성됩니다.

슬로우 쿼리 로그는, 실행에 시간이 걸려, 최적화의 대상이 되는 쿼리를 찾아내기 위해서 사용할 수 있습니다.큰 로그에서는, 이것은 어려운 작업이 됩니다.mysqldumpslow 커멘드를 사용하면, 로그의 쿼리 요약을 취득할 수 있습니다.

--log-long-format (을)를 사용하면, 인덱스를 사용하지 않았던 쿼리도 출력됩니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

MySQL 서버에서는 몇개의 종류의 로그 파일이 생성되어 실행 내용을 간단하게 확인할 수 있습니다.See 항4.10. 「MySQL 로그 파일」 . 다만, 로그가 디스크 영역을 점유 너무 하지 않게 이러한 파일을 정기적으로 클린 업 할 필요가 있습니다.

MySQL (을)를 로그 파일과 함께 사용하는 경우, 정기적으로 낡은 파일을 삭제 또는 백업 해, 새로운 파일로 로그를 개시하도록 해 주세요. See 항4.5.1. 「데이타베이스의 백업」 .

Linux (Red Hat ) 인스톨에서는,mysql-log-rotate 스크립트를 사용하고, 낡은 로그 파일의 처리를 자동적으로 실시할 수 있습니다.RPM 디스트리뷰션으로부터 MySQL (을)를 인스톨 하고 있으면, 이 스크립트는 자동적으로 인스톨 되고 있을 것입니다.주의: replication용으로 바이너리 로그를 사용하고 있는 경우, 이 스크립트의 사용에는 주의가 필요합니다.

다른 시스템에서는, 로그 파일을 처리하기 위한 짧은 스크립트를 스스로 인스톨 할 필요가 있습니다.이 스크립트는,cron (으)로부터 개시합니다.

새로운 로그 파일의 사용을 MySQL 에 강제하려면 ,mysqladmin flush-logs (을)를 사용하는지,SQL 커멘드 FLUSH LOGS (을)를 사용합니다. MySQL 버젼 3.21 (을)를 사용하고 있는 경우,mysqladmin refresh (을)를 사용할 필요가 있습니다.

상기 커멘드는 이하를 실행합니다.

갱신 로그만을 사용하고 있는 경우는, 로그를 플래시 하고, 낡은 갱신 로그 파일을 백업으로 이동하는 것만으로 끝납니다. 통상의 로그를 사용하고 있는 경우는, 이하와 같이 실시합니다.

shell> cd mysql-data-directory
shell> mv mysql.log mysql.old
shell> mysqladmin flush-logs

다음에, 백업을 작성해,mysql.old (을)를 삭제합니다.