ref.
http://database.sarang.net/?inc=read&aid=24921&criteria=mysql&subcrit=columns&id=&limit=20&keyword=&page=1
5.11.1 The Error Log
The error log는 서버가 시작, 종료시간, 치명적인 에러를 저장한다.
예기치 못한 서버종료와 재시작이 필요한 경우, 테이블에 에러가 있어 자동으로 복구한 경우 로그를 남깁니다.
OS에 따라 서버가 종료될 때 a stack trace가 남는데, 어떤 동작을 하다 종료되었는지 알 수 있다. (E.1.4, “Using a Stack Trace”. 을 참고하라.)
--log-error[=file_name] 옵션으로 로그파일 이름과 저장경로를 지정할 수 있다. (기본 host_name.err, data directory)
FLUSH LOGS를 실행하면 파일 이름에 -old 문자를 추가하고 새로운 로그파일을 만든다. --log-error 옵션이 없다면 파일이름을 바꾸지 않는다.
--log-error 가 없거나 윈도우 시스템에서 --console 옵션을 사용하면 에러는 the standard에 기록된다.
윈도우 시스템에서 --console 옵션이 없다면 .err 파일에 기록된다.
5.11.2 The General Query Log
--log[=file_name] or -l [file_name] 옵션으로 사용하면 MySQL에서 발생하는 것을 기록한다.
기본 로그파일명은 host_name.log 이다.
접속기록과 실행문장을 기록한다.
사용자에게 에러가 발생한 내용이나 사용자가 실행한 내용을 알아내는데 유용하다.
로그는 실제 실행된 순서와 다를 수도 있다. 이것은 쿼리문이 실행될 때 기록되는 update log 와 binary log와는 달리 락이 풀릴 때 (실행이 완료될 때)를 기준으로 로그가 기록되기 때문이다.
이 로그는 모든 문장을 포함하지만 binary log는 select 같은 문장은 포함하지 않는다.
서버가 재시작 되거나 FLUSH LOGS를 실행하여도 새로운 로그파일을 만들지 않는다.
윈도우 시스템에서는 서버를 중지하고 파일이름을 변경하여야 하고 다른 시스템은 아래 실행문으로 변경할 수 있다.
shell> mv hostname.log hostname-old.log
shell> mysqladmin flush-logs
shell> cp hostname-old.log to-backup-directory
shell> rm hostname-old.log
5.11.3 The Binary Log
Binary Log는 더 효과적인 포맷과 트랜잭션을 포함하여 Update Log 에 있는 유용한 모든 정보를 저장하고 있다. Binary Log는 데이타를 업데이트하는 모든 문장과 수정하지 않는 문장(일치하는 값이 없는 Delete 문) 을 저장한다. 문장은 수정된 내용을 표현하는 이벤트의 형식으로 저장된다. Binary Log는 Update Log 대신 사용해 왔다. Update Log는 MySQL5.0에서는 사용할 수 없다.
Binary Log는 각각의 문장이 데이타베이스를 업데이트하는데 걸린 신간도 포함하고 있다. 데이타를 수정하지 않는 문장은 포함하지 않는다. 만일 장애 수정등의 쿼리문을 보고싶다면 General Query Log를 사용하라.
Binary Log를 사용하는 첫번째 이유는 백업된 이후에 모든 업데이트 문장을 포함하고 있기 때문에 복구명령을 사용할 때 가능한 모든 부분을 업데이트하기 위한 것이다.
Binary Log는 slave서버에 전송된 문장들이 기록되어 replication server에 사용된다.
Binary Log를 사용하면 시스템 성능이 1%정도가 감소하지만 복구와 백업서버 운영에 상당히 유용하다.
--log-bin[=file_name] 옵션으로 시작하면 모든 데이타를 수정하는 SQL명령을 기록한다. 파일명을 기입하지 않으면 -bin다음에 호스트명이 파일명이 된다. 경로가 없는 파일명은 데이타 디렉터리가 기본이 된다.
파일에 확정자를 붙여도 숫자로된 확장자가 자동으로 붙는다. 서버가 재시작하거나 Flush Logs를 실행하면 숫자가 자동 증가한다. 또한 로그파일 크기가 max_binlog_size 에 도달하면 자동으로 증가한다. 많은 양의 트랜잭션을 사용하면 트랜잭션 로그는 로그파일에 나눠서 저장될 수 없기 때문에 max_binlog_size가 조금 커질 수도 있다.
어떤 binary log 파일들이 사용되었는지 알기 위해 사용된 파일이름을 저장하는 인덱스파일을 만든다. 파일명은 로그파일명, 확장자는 .index로 생성되는데 --log-bin-index[=file_name] 을 사용하여 파일명을 지정할 수 있다. 서버가 실행중일 때는 수동으로 편집할 수 없다.
모든 binary log파일은 RESET MASTER 문과 PURGE MASTER LOGS 문으로 삭제할 수 있다. Section 13.5.5.5, “RESET Syntax” and Section 13.6.1, “SQL Statements for Controlling Master Servers” 부분을 참고.
binary log format 은 백업과 복구에 제한이 있는데 Section 6.7, “Replication Features and Known Problems” 부분을 참고하라.
Binary logging 에서 프로시저(stored routines) 와 트리거(triggers)는 Section 17.4, “Binary Logging of Stored Routines and Triggers”를 참고하라.
다음은 binary log에 사용되는 옵션이다.
--binlog-do-db=db_name
db_name 은 binary log 를 사용할 디비를 선택하는 옵션이다. 선택되지 않은 디비는 로그가 남지 않고 현재 작업중인 디비를 업데이트 한다는 것을 확인하기 바란다.
Tells the master that it should log updates to the binary log if the current database (that is, the one selected by USE) is db_name. All other databases that are not explicitly mentioned are ignored. If you use this, you should ensure that you only do updates in the current database.
CREATE DATABASE, ALTER DATABASE, and DROP DATABASE 문장은 예외이다. (현재 디비의 로그를 남겨야 할지 명확하지 않는 문장인 구문이기 때문이다.)
Observe that there is an exception to this as regards the CREATE DATABASE, ALTER DATABASE, and DROP DATABASE statements, which use the database manipulated to decide if it should log the statement rather than the current database.
예상한 것과 다르게 로그가 남기는 예로
sales 디비를 사용하는 옵션(binlog-do-db=sales)으로 서버를 시작하여 prices 디비를 사용하다 UPDATE sales.january SET amount=amount+1000;라는 쿼리문을 실행하면 이 로그는 binary log에 남지 않는다.
An example of what does not work as you might expect: If the server is started with binlog-do-db=sales, and you do USE prices; UPDATE sales.january SET amount=amount+1000;, this statement does not get written into the binary log.
--binlog-ignore-db=db_name
현재 사용중인 디비에서 실행한 쿼리문의 로그가 저장되지 않는다.
Tells the master that updates where the current database (that is, the one selected by USE) is db_name should not be stored in the binary log. If you use this, you should ensure that you only do updates in the current database.
위에 거와 같음.
An example of what does not work as you might expect: If the server is started with binlog-ignore-db=sales, and you do USE prices; UPDATE sales.january SET amount=amount+1000;, this statement is not written into the binary log.
--binlog-do-db 옵션과 비슷한 경우로 CREATE DATABASE, ALTER DATABASE, and DROP DATABASE 문은 로그가 없다.
Similar to the case for --binlog-do-db, there is an exception to the CREATE DATABASE, ALTER DATABASE, and DROP DATABASE statements, which use the database manipulated to decide if it should log the statement rather than the current database.
여러개의 디비를 지정하려면 각각의 디비마다 적당한 옵션을 실행해야 한다.
To log or ignore multiple databases, use multiple options, specifying the appropriate option once for each database.
아래 규칙에 따라 binary log 에 업데이트할지 옵션을 활성화 한다. CREATE/ALTER/DROP DATABASE 문은 예외이다.
The server evaluates the options for logging or ignoring updates to the binary log according to the following rules. Observe that there is an exception for CREATE/ALTER/DROP DATABASE statements. In those cases, the database being created, altered, or dropped replaces the current database in the rules below.
Are there binlog-do-db or binlog-ignore-db rules?
No: Write the statement to the binary log and exit.
Yes: Go to the next step.
There are some rules (binlog-do-db or binlog-ignore-db or both). Is there a current database (has any database been selected by USE?)?
No: Do not write the statement, and exit.
Yes: Go to the next step.
There is a current database. Are there some binlog-do-db rules?
Yes: Does the current database match any of the binlog-do-db rules?
Yes: Write the statement and exit.
No: Do not write the statement, and exit.
No: Go to the next step.
There are some binlog-ignore-db rules. Does the current database match any of the binlog-ignore-db rules?
Yes: Do not write the statement, and exit.
No: Write the query and exit.
예를 들어 only binlog-do-db=sales 옵션으로 운영되는 슬레이브 서버는 현재 사용중인 디비가 sales 일지라도 binary log에 로그를 남기지 않는다. (다른 말로 binlog-do-db는 때로 다른 디비는 무시하라(ignore other databases) 를 의미하기 때문이다. 슬레이브는 다른 컴퓨터니까 다른 디비로 인식한다는 것 같은데요.)
For example, a slave running with only binlog-do-db=sales does not write to the binary log any statement whose current database is different from sales (in other words, binlog-do-db can sometimes mean “ignore other databases”).
만약 복제서버를 운영하고 있다면 모든 슬레이브 서버가 더이상 binary log 를 필요하지 않을 때 삭제해야 한다. 간단한 예로 매일 mysqladmin flush-logs 명령을 한번 실행하고 3일전에 실행한 로그를 지워라. 수동으로 지우던가 binary log에 대한 인덱스 파일을 안전하게 업데이트 하려면 PURGE MASTER LOGS를 사용하여 지워라. Section 13.6.1, “SQL Statements for Controlling Master Servers” 참고.
If you are using replication, you should not delete old binary log files until you are sure that no slave still needs to use them. One way to do this is to do mysqladmin flush-logs once a day and then remove any logs that are more than three days old. You can remove them manually, or preferably using PURGE MASTER LOGS (see Section 13.6.1, “SQL Statements for Controlling Master Servers”), which also safely updates the binary log index file for you (and which can take a date argument).
SUPER 권한(루트권한?) 이 있는 사용자는 SET SQL_LOG_BIN=0 문을 사용하여 로그에 로그를 안남길 수 있다. Section 13.5.3, “SET Syntax” 참고.
A client with the SUPER privilege can disable binary logging of its own statements by using a SET SQL_LOG_BIN=0 statement. See Section 13.5.3, “SET Syntax”.
mysqlbinlog 유틸을 사용하여 binary log 파일을 확인할 수 있다. 로그파일에 있는 기록을 다시 실행할 때 유용하다. 예를 들어 아래처럼 binary log 를 이용하여 서버를 업데이트 할 수 있다.
You can examine the binary log file with the mysqlbinlog utility. This can be useful when you want to reprocess statements in the log. For example, you can update a MySQL server from the binary log as follows:
shell> mysqlbinlog log-file | mysql -h server_name
더 많은 mysqlbinlog에 대한 정보와 사용법은 Section 8.6, “mysqlbinlog ? Utility for Processing Binary Log Files” 을 참고.
See Section 8.6, “mysqlbinlog ? Utility for Processing Binary Log Files” for more information on the mysqlbinlog utility and how to use it.
트랜잭션을 사용한다면 백업을 위해 update log 대신에 MySQL binary log를 이용해야 한다.
If you are using transactions, you must use the MySQL binary log for backups instead of the old update log.
binary log 는 쿼리가 완료된 직후에 기록된다. 이것은 테이블의 락이 풀리거나 commit 명령이 완료되기 전일 수도 있다. 즉, 실행 순서에 따라 로그가 기록된다는 것이다.
The binary logging is done immediately after a query completes but before any locks are released or any commit is done. This ensures that the log is logged in the execution order.
트랜잭션을 사용하지 않는 테이블은 실행된 직후에 binary log에 저장된다. BDB or InnoDB 같은 트랜잭션 테이블에서 테이블을 변경하는 모든 업데이트문장은 COMMIT 명령이 서버로부터 전달될 때까지 적용하지 않지만 COMMIT 명령이 실행되기 전에 모든 트랜잭션은 binary log에 저장된다. 트랜잭션을 관리하는 스레드가 시작되면 buffer queries 에 buffer of binlog_cache_size 를 할당한다. 만일 문장 크기가 더 크다면 스레드는 스랜잭션을 임시파일에 저장한다. 스레드가 종료되면 임시파일은 삭제된다.
Updates to non-transactional tables are stored in the binary log immediately after execution. For transactional tables such as BDB or InnoDB tables, all updates (UPDATE, DELETE, or INSERT) that change tables are cached until a COMMIT statement is received by the server. At that point, mysqld writes the whole transaction to the binary log before the COMMIT is executed. When the thread that handles the transaction starts, it allocates a buffer of binlog_cache_size to buffer queries. If a statement is bigger than this, the thread opens a temporary file to store the transaction. The temporary file is deleted when the thread ends.
Binlog_cache_use 의 상태변수를 보면 쿼리문을 저장하는데 이 버퍼(임시파일 포함)를 사용하는 트랜잭션 수를 알 수 있다. Binlog_cache_disk_use는 얼마나 많은 트랜잭션이 실제로 사용한 임시파일 수를 알 수 있다. 이 변수들은 임시파일을 사용하지 않을 정도의 충분한 binlog_cache_size 용량을 튜닝하는데 유용하다.
The Binlog_cache_use status variable shows the number of transactions that used this buffer (and possibly a temporary file) for storing statements. The Binlog_cache_disk_use status variable shows how many of those transactions actually did have to use a temporary file. These two variables can be used for tuning binlog_cache_size to a large enough value that avoids the use of temporary files.
max_binlog_cache_size 는 4G가 기본이고 트랜잭션이 이보다 클경우 모두 롤백된다.
The max_binlog_cache_size (default 4GB) can be used to restrict the total size used to cache a multiple-statement transaction. If a transaction is larger than this, it fails and rolls back.
update log 또는 binary log를 사용하고 있다면 CREATE ... SELECT 또는 INSERT ... SELECT 를 사용할 때 concurrent inserts은 normal inserts 로 변환된다. 백업된 로그를 적용해서 동일한 테이블을 생성할 수 있다.
If you are using the update log or binary log, concurrent inserts are converted to normal inserts when using CREATE ... SELECT or INSERT ... SELECT. This is to ensure that you can re-create an exact copy of your tables by applying the log on a backup.
MySQL 5.0에서 binary log format은 복제기능 향상을 위해 이전의 다른 버전과 다르게 되어 있다.
Note that the binary log format is different in MySQL 5.0 from previous versions of MySQL, due to enhancements in replication. See Section 6.5, “Replication Compatibility Between MySQL Versions”.
기본적으로 binary log 는 모든 쓰기문장을 디스크에 동시에 저장하지는 않는다. OS에서 충돌이 발생하면 마지막 쿼리문을 기록하지 로그에 기록하지 않을 수 있다. 이것을 막으려면, sync_binlog global variable를 사용하여 Nth binary log 를 기록한 후에 바로 디스크에 기록할 수 있다. (1로 설정하는 것이 가장 안전하지만 가장 느리다.) Section 5.3.3, “Server System Variables” 참고.
sync_binlog 을 1로 설정하더라도 시스템상에 충돌이 있다면 테이블과 로그의 값이 다를 수 있다. 예를 들어 InnoDB 테이블을 사용하면서 COMMIT 명령이 실행되면 모든 트랜잭션을 binary log 에 저장하고 InnoDB 에 값을 적용한다. 두가지 수행과정중 충돌이 발생하면 InnoDB에 의해 트랜잭션은 롤백되지만 binary log에 여전히 로그가 남아 있게 된다. 이 문제를 해결하려면 --innodb-safe-binlog 옵션을 사용해야 InnoDB 테이블과 binary log 사이에 일관성이 유지된다. (Note: --innodb-safe-binlog 는 MySQL 5.0.3 버젼에서는 필요하지 않다. 이 문서는 XA 트랜잭션 지원을 위해서 만들어 졌다.)
By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes, there is a chance that the last statements of the binary log are lost. To prevent this, you can make the binary log be synchronized to disk after every Nth binary log write, with the sync_binlog global variable (1 being the safest value, but also the slowest). See Section 5.3.3, “Server System Variables”. Even with sync_binlog set to 1, there is still the chance of an inconsistency between the tables content and the binary log content in case of crash. For example, if using InnoDB tables, and the MySQL server processes a COMMIT statement, it writes the whole transaction to the binary log and then commits this transaction into InnoDB. If it crashes between those two operations, at restart the transaction is rolled back by InnoDB but still exists in the binary log. This problem can be solved with the --innodb-safe-binlog option, which adds consistency between the content of InnoDB tables and the binary log. (Note: --innodb-safe-binlog is unneeded as of MySQL 5.0.3; it was made obsolete by the introduction of XA transaction support.)
더 향상된 안전성을 위해 MySQL 서버는 모든 트랜잭션에 대해 디스크와 binary logsync_binlog=1, InnoDB logs(기본설정) 를 동시에 작업한다. 이 옵션은 충돌이 발생한 이후 재시작할 때 트랜잭션을 롤백하고 binary log에서 InnoDB 트랜잭션을 하지 못하게 막는다. binary log는 InnoDB 테이블의 정확한 데이타를 반영하고 슬레이브 서버 또한 주 서버와 일관성을 유지하게 한다.
For this option to provide a greater degree of safety, the MySQL server should also be configured to synchronize to disk, at every transaction, the binary log (sync_binlog=1) and (which is true by default) the InnoDB logs. The effect of this option is that at restart after a crash, after doing a rollback of transactions, the MySQL server cuts rolled back InnoDB transactions from the binary log. This ensures that the binary log reflects the exact data of InnoDB tables, and so, that the slave remains in sync with the master (not receiving a statement which has been rolled back).
--innodb-safe-binlog 옵션은 InnoDB가 아닌 다른 저장엔진을 업데이트할 때에도 사용된다. 단지 InnoDB 테이블에 영향을 미치는 문장/트랜잭션이 InnoDB의 충돌이 발생할 때 binary log에서 삭제된다는 것이 핵심이다.
만일 충돌 복구 과정에서 (sync_binlog=1 이고 the disk/filesystem이 동일성이 유지된다면 발생하지 않지만) binary log 가 더 짧아진 것을 발견한다면 에러 메시지("The binary log <name> is shorter than its expected size")를 출력할 것이다.
이런경우 binary log 는 부정확한 것이고 복제서버는 정확한 주서버의 데이타로 다시 시작해야 한다.
Note that --innodb-safe-binlog can be used even if the MySQL server updates other storage engines than InnoDB. Only statements/transactions affecting InnoDB tables are subject to being removed from the binary log at InnoDB's crash recovery. If at crash recovery the MySQL server discovers that the binary log is shorter than it should have been (that is, it lacks at least one successfully committed InnoDB transaction), which should not happen if sync_binlog=1 and the disk/filesystem do an actual sync when they are requested to (some don't), it prints an error message ("The binary log <name> is shorter than its expected size"). In this case, this binary log is not correct, replication should be restarted from a fresh master's data snapshot.
binary log file 과 binary log index file에 기록하는 것은 MyISAM 테이블과 같은 방식으로 기록한다. Section A.4.3, “How MySQL Handles a Full Disk” 참고.
Writes to the binary log file and binary log index file are handled in the same way as writes to MyISAM tables. See Section A.4.3, “How MySQL Handles a Full Disk”.
아래는 게시물 올라온건데 그냥 올려봅니다.
I spend 2 hours figuring out why it does not work on Windows.
Finally added under [mysqld]
set-variable=log-bin=C:\mysql\data (C:/mysql/data )
If you are doing bin-log on a slave server -- for instance for backup in the slave machine -- remember to use the option "--log-slave-updates".
5.11.4. The Slow Query Log
--log-slow-queries[=file_name] 옵션은 long_query_time 에 설정한 시간보다 실행시간이 더 긴 문장을 로그에 저장한다. 테이블에 락을 하는 시간은 실행시간에 포함되지 않는다. long_query_time 의 최소시간은 1초이다.
파일명이 없으면 기본파일명은 -slow.log 뒤에 호스트명이 붙고 경로가 없으면 data directory에 저장된다.
쿼리문이 실행되고 모든 락이 풀린 후에 로그에 저장된다. 저장된 순서는 실제 실행 순서와 차이가 있을 수 있다.
실행하는데 오랜 시간이 걸린 쿼리문을 알아내어 최적화 또는 튜닝에 도움이 된다.
로그에 많은 기록이 있다면 로그의 요약된 쿼리문을 얻기 위해 mysqldumpslow 명령을 사용하기 바란다.
인덱스를 사용하지 않는 쿼리문이 많이 저장될 수 있는데 인덱스를 사용하지 않는 느린 쿼리문을 저장하고 싶지 않다면 --log-short-format 옵션을 사용해라. mysqld Command-Line Options 참고.
OPTIMIZE TABLE, ANALYZE TABLE, and ALTER TABLE 같은 관리자 명령을 로그에 저장하고 싶다면 --log-slow-admin-statements 옵션을 사용해라.
query cache 에 의해 수행되는 쿼리문은 로그에 남지 않고, 열이 없거나 하나있는 테이블에는 인덱스가 하나 있는 쿼리문도 로그에 남지 않는다.
5.11.5. Log File Maintenance
서버는 여러개의 로그파일을 작성하여 서버가 무슨 일을 하고 있는지 쉽게 알 수 있게 해준다. 그러나 로그파일이 많은 디스크용량을 차지하지 않게 주기적으로 로그관리를 하여야 한다.
주기적으로 백업하고 오래된 로그파일을 지우고 새로운 로그파일을 만들고 싶다면 5.9.1, “Database Backups” 부분을 보세요.
Linux (Red Hat) 에서는 mysql-log-rotate script 를 사용할 수 있다. RPM 으로 설치하였다면 자동으로 설치되어 있다. 복제서버에 binary log 를 사용하고 있다면 이 기능을 조심스럽게 사용하기 바란다. 모든 복제서버에 정상적으로 적용되었다고 확신하기 전에는 binary logs 파일을 삭제하지 말라.
다른 시스템에서 이 기능을 사용하고 싶다면 cron 이나 로그를 관리할 수 있는 프로그램을 스스로 설치하여 사용하기 바란다.
mysqladmin 에서 flush-logs 나 SQL 문에서 FLUSH LOGS 를 사용하여 새로운 로그파일을 생성할 수 있다.
FLUSH LOGS 명령은 다음과 같은 작업을 한다.
=> --log 또는 --log-slow-queries 옵션을 사용하고 있다면 로그파일을 닫았다 다시 연다. (기본파일명 mysql.log and `hostname`-slow.log)
=> --log-update 또는 --log-bin 옵션을 사용하고 있다면 로그를 닫고 새로운 파일명(시퀀스-숫자를 추가하여)의 로그파일을 만든다.
=> update log만 사용하고 있다면 파일명을 바꾼 후 FLUSH LOGS 를 실행하고 DB 백업을 하기 바란다
