Loading...
MySQL 9.5 Reference Manual 9.5의 7.4.4 The Binary Log의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
binary log에는 테이블 생성 작업이나 테이블 데이터 변경과 같은 데이터베이스 변경 사항을 설명하는 “event”가 포함됩니다. 또한 변경을 일으켰을 가능성이 있는 스테이트먼트(예를 들어, 어떤 row와도 매칭되지 않은 DELETE)에 대한 event도 포함됩니다(단, row-based logging을 사용하는 경우는 제외). binary log에는 데이터를 갱신한 각 스테이트먼트가 얼마나 오래 걸렸는지에 대한 정보도 포함됩니다.
binary log는 다음과 같은 두 가지 중요한 목적을 가집니다:
복제를 사용하는 경우, 복제 소스 서버의 binary log는 레플리카로 전송될 데이터 변경 사항의 기록을 제공합니다. 소스는 자신의 binary log에 포함된 정보를 레플리카로 전송하고, 레플리카는 그 트랜잭션들을 재실행하여 소스에서 수행된 것과 동일한 데이터 변경을 수행합니다. 자세한 내용은 Section 19.2, “Replication Implementation”을 참조하십시오.
특정 데이터 복구 작업에는 binary log 사용이 필요합니다. 백업을 복원한 후에, 백업이 수행된 이후에 binary log에 기록된 event를 재실행합니다. 이러한 event는 백업 시점 이후부터 데이터베이스를 최신 상태로 맞춥니다. 자세한 내용은 Section 9.5, “Point-in-Time (Incremental) Recovery”를 참조하십시오.
binary log는 데이터를 수정하지 않는 SELECT나 SHOW와 같은 스테이트먼트에는 사용되지 않습니다. 모든 스테이트먼트를 기록하려면(예를 들어 문제를 일으키는 쿼리를 식별하기 위해), general query log를 사용하십시오. Section 7.4.3, “The General Query Log”를 참조하십시오.
binary logging을 활성화한 상태로 서버를 실행하면 성능이 약간 느려집니다. 그러나 복제 구성과 복구 작업을 가능하게 해주는 binary log의 이점은 일반적으로 이러한 성능 저하보다 더 큽니다.
binary log는 예기치 않은 중지 상황에 대해 탄력성을 가집니다. 완료된 event나 트랜잭션만이 기록되거나 다시 읽힙니다.
binary log에 기록되는 스테이트먼트에 포함된 패스워드는 서버에 의해 일반 텍스트로 그대로 나타나지 않도록 다시 작성됩니다. 자세한 내용은 Section 8.1.2.3, “Passwords and Logging”을 참조하십시오.
MySQL binary log 파일과 relay log 파일은 암호화할 수 있으며, 이를 통해 이들 파일과 그 안에 포함될 수 있는 민감한 데이터를 외부 공격자에 의한 오용으로부터 보호하고, 또한 해당 파일이 저장된 운영체제의 사용자에 의한 무단 열람으로부터 보호할 수 있습니다. MySQL 서버에서 암호화를 활성화하려면 binlog_encryption 시스템 변수를 ON으로 설정하십시오. 자세한 내용은 Section 19.3.2, “Encrypting Binary Log Files and Relay Log Files”를 참조하십시오.
다음 설명에서는 binary logging 동작에 영향을 주는 일부 서버 옵션과 변수에 대해 다룹니다. 전체 목록은 Section 19.1.6.4, “Binary Logging Options and Variables”를 참조하십시오.
binary logging은 기본적으로 활성화되어 있습니다(log_bin 시스템 변수가 ON으로 설정됨). 예외는 데이터 디렉터리를 수동으로 초기화하기 위해 mysqld를 --initialize 또는 --initialize-insecure 옵션과 함께 호출하는 경우입니다. 이때는 binary logging이 기본적으로 비활성화되지만, --log-bin 옵션을 지정하여 활성화할 수 있습니다.
binary logging을 비활성화하려면, 시작 시 --skip-log-bin 또는 --disable-log-bin 옵션을 지정하면 됩니다. 이들 옵션 중 하나와 --log-bin을 동시에 지정한 경우, 나중에 지정된 옵션이 우선합니다.
--log-replica-updates 및 --replica-preserve-commit-order 옵션은 binary logging이 필요합니다. binary logging을 비활성화하는 경우, 이 옵션들을 생략하거나 --log-replica-updates=OFF 및 --skip-replica-preserve-commit-order를 지정해야 합니다. MySQL은 --skip-log-bin 또는 --disable-log-bin이 지정되면 이러한 옵션들을 기본적으로 비활성화합니다. --log-replica-updates 또는 --replica-preserve-commit-order를 --skip-log-bin 또는 --disable-log-bin과 함께 지정하면, 경고 또는 에러 메시지가 발생합니다.
--log-bin[=base_name] 옵션은 binary log 파일의 기본 이름(base name)을 지정하는 데 사용됩니다. --log-bin 옵션을 제공하지 않으면, MySQL은 binary log 파일의 기본 base name으로 binlog를 사용합니다. 이전 릴리스와의 호환성을 위해, 문자열 없이 또는 빈 문자열로 --log-bin 옵션을 제공하면 base name은 호스트 머신의 이름을 사용한 host_name-bin으로 기본 설정됩니다. 호스트 이름이 변경되더라도 동일한 binary log 파일 이름을 계속 사용할 수 있도록 base name을 지정하는 것이 좋습니다(자세한 내용은 Section B.3.7, “Known Issues in MySQL”을 참조하십시오). 로그 이름에 확장자를 포함하여 지정하는 경우(예: --log-bin=base_name.extension), 해당 확장자는 조용히 제거되고 무시됩니다.
mysqld는 binary log 파일 이름을 생성하기 위해 binary log base name에 숫자 확장자를 덧붙입니다. 서버가 새로운 로그 파일을 생성할 때마다 이 숫자는 증가하여, 순서가 있는 일련의 파일을 생성합니다. 서버는 다음 중 하나의 event가 발생할 때마다 이 시리즈에서 새로운 파일을 생성합니다:
서버가 시작되거나 재시작될 때
서버가 로그를 flush할 때.
현재 로그 파일의 크기가 max_binlog_size에 도달할 때.
large 트랜잭션을 사용하는 경우, 트랜잭션은 하나의 조각으로 파일에 기록되고 파일 사이에 나뉘지 않으므로, binary log 파일의 크기는 max_binlog_size를 초과할 수 있습니다.
어떤 binary log 파일이 사용되었는지 추적하기 위해, mysqld는 binary log 파일의 이름을 포함하는 binary log 인덱스 파일도 생성합니다. 기본적으로 이 파일은 binary log 파일과 동일한 base name을 사용하며 확장자는 '.index'입니다. --log-bin-index[=file_name] 옵션을 사용하여 binary log 인덱스 파일의 이름을 변경할 수 있습니다. mysqld가 실행 중일 때는 이 파일을 수동으로 편집해서는 안 됩니다. 그렇게 하면 mysqld 동작이 혼란스러워집니다.
“binary log 파일”이라는 용어는 일반적으로 데이터베이스 event를 포함하는 개별 번호가 매겨진 파일을 의미합니다. “binary log”라는 용어는 번호가 매겨진 binary log 파일 집합과 인덱스 파일 전체를 통칭합니다.
binary log 파일과 binary log 인덱스 파일의 기본 위치는 데이터 디렉터리입니다. 다른 위치를 사용하려면 --log-bin 옵션에 base name 앞에 절대 경로명을 추가하여 다른 디렉터리를 지정할 수 있습니다. 서버는 사용된 binary log 파일을 추적하는 binary log 인덱스 파일에서 엔트리를 읽을 때, 그 엔트리에 상대 경로가 포함되어 있는지 확인합니다. 포함되어 있다면, 경로의 상대 부분을 --log-bin 옵션으로 설정된 절대 경로로 대체합니다. binary log 인덱스 파일에 기록된 절대 경로는 변경되지 않습니다. 이런 경우, 새로운 경로를 사용하려면 인덱스 파일을 수동으로 편집해야 합니다. binary log 파일 base name과 지정된 경로는 log_bin_basename 시스템 변수로 확인할 수 있습니다.
binary logging이 활성화된 상태에서 서버를 기본 서버 ID로 시작할 수 있지만, server_id 시스템 변수를 사용해서 서버 ID를 명시적으로 지정하지 않으면 정보성 메시지가 출력됩니다. 복제 토폴로지에서 사용되는 서버의 경우, 각 서버에 대해 0이 아닌 고유한 서버 ID를 지정해야 합니다.
제한된 세션 시스템 변수를 설정할 수 있는 충분한 권한을 가진 클라이언트(Section 7.1.9.1, “System Variable Privileges” 참조)는 SET sql_log_bin=OFF 스테이트먼트를 사용하여 자신의 스테이트먼트에 대한 binary logging을 비활성화할 수 있습니다.
기본적으로 서버는 event 자체와 함께 event의 길이도 로그에 기록하며, 이를 사용해서 event가 올바르게 기록되었는지 검증합니다. binlog_checksum 시스템 변수를 설정하여 서버가 event에 대해 체크섬도 기록하도록 할 수 있습니다. binary log로부터 다시 읽을 때, 소스는 기본적으로 event 길이를 사용하지만, source_verify_checksum를 활성화하면 사용 가능한 경우 체크섬을 사용하도록 할 수 있습니다. 레플리카의 복제 I/O(receiver) 스레드도 소스로부터 수신한 event를 검증합니다. relay log에서 읽을 때 레플리카의 복제 SQL(applier) 스레드가 사용 가능한 경우 체크섬을 사용하도록 하려면 replica_sql_verify_checksum를 활성화하십시오.
binary log에 기록되는 event의 형식은 binary logging 포맷에 따라 달라집니다. 세 가지 포맷 타입이 지원됩니다: row-based logging, statement-based logging 및 mixed-base logging입니다. 사용되는 binary logging 포맷은 MySQL 버전에 따라 다릅니다. logging 포맷에 대한 설명은 Section 7.4.4.1, “Binary Logging Formats”을 참조하십시오.
서버는 --binlog-do-db 및 --binlog-ignore-db 옵션을 --replicate-do-db 및 --replicate-ignore-db 옵션과 동일한 방식으로 평가합니다. 이 평가 방식에 대한 정보는 Section 19.2.5.1, “Evaluation of Database-Level Replication and Binary Logging Options”을 참조하십시오.
레플리카는 기본적으로 log_replica_updates가 활성화된 상태로 시작되며, 이는 레플리카가 소스로부터 수신한 데이터 수정 내용을 자신의 binary log에 기록한다는 의미입니다. 이 설정이 동작하려면 binary log가 활성화되어야 합니다(Section 19.1.6.3, “Replica Server Options and Variables” 참조). 이 설정을 통해 레플리카가 다른 레플리카의 소스로 동작할 수 있습니다.
RESET BINARY LOGS AND GTIDS 스테이트먼트를 사용하여 모든 binary log 파일을 삭제할 수 있으며, PURGE BINARY LOGS를 사용하여 그 중 일부만 삭제할 수도 있습니다. Section 15.7.8.6, “RESET Statement” 및 Section 15.4.1.1, “PURGE BINARY LOGS Statement”를 참조하십시오.
MySQL Replication을 사용하는 경우, 어떤 레플리카도 더 이상 해당 로그를 필요로 하지 않는다는 것이 확실해질 때까지 소스에서 오래된 binary log 파일을 삭제해서는 안 됩니다. 예를 들어, 레플리카가 세 날 이상 지연되지 않는다면, 하루에 한 번 소스에서 mysqladmin flush-logs binary를 실행하고, 그런 다음 3일보다 더 오래된 로그를 제거할 수 있습니다.
파일을 수동으로 제거할 수도 있지만, binary log 인덱스 파일도 안전하게 갱신해 주고 date 인수를 받을 수 있는 PURGE BINARY LOGS를 사용하는 것이 더 바람직합니다. Section 15.4.1.1, “PURGE BINARY LOGS Statement”를 참조하십시오.
mysqlbinlog 유틸리티를 사용하여 binary log 파일의 내용을 표시할 수 있습니다. 이는 복구 작업을 위해 로그의 스테이트먼트를 다시 처리하려는 경우에 유용합니다. 예를 들어, binary log로부터 MySQL 서버를 다음과 같이 갱신할 수 있습니다:
1$> mysqlbinlog log_file | mysql -h server_name
mysqlbinlog는 또한 레플리카의 relay log 파일 내용도 표시하는 데 사용할 수 있는데, relay log 파일도 binary log 파일과 동일한 포맷으로 기록되기 때문입니다. mysqlbinlog 유틸리티 및 그 사용 방법에 대한 더 많은 정보는 Section 6.6.9, “mysqlbinlog — Utility for Processing Binary Log Files”를 참조하십시오. binary log와 복구 작업에 대한 추가 정보는 Section 9.5, “Point-in-Time (Incremental) Recovery”를 참조하십시오.
binary logging은 스테이트먼트나 트랜잭션이 완료된 직후, 그러나 어떠한 lock도 해제되기 전이거나 커밋이 수행되기 전에 즉시 수행됩니다. 이는 로그가 커밋 순서대로 기록되도록 보장합니다.
nontransactional 테이블에 대한 업데이트는 실행 직후 binary log에 저장됩니다.
커밋되지 않은 트랜잭션 내에서, InnoDB 테이블과 같은 transactional 테이블을 변경하는 모든 업데이트(UPDATE, DELETE 또는 INSERT)는 서버가 COMMIT 스테이트먼트를 수신할 때까지 캐시됩니다. 그 시점에 mysqld는 COMMIT이 실행되기 전에 전체 트랜잭션을 binary log에 기록합니다.
nontransactional 테이블에 대한 변경은 롤백할 수 없습니다. 롤백된 트랜잭션에 nontransactional 테이블에 대한 변경이 포함되어 있으면, 해당 트랜잭션 전체가 그 테이블에 대한 변경이 복제되도록 하기 위해 끝에 ROLLBACK 스테이트먼트와 함께 로그에 기록됩니다.
트랜잭션을 처리하는 스레드가 시작되면, 스테이트먼트를 버퍼링하기 위해 binlog_cache_size 크기의 버퍼를 할당합니다. 스테이트먼트가 이보다 크면 스레드는 트랜잭션을 저장하기 위한 임시 파일을 엽니다. 스레드가 종료되면 임시 파일은 삭제됩니다. 서버에서 binary log 암호화가 활성화되어 있으면, 임시 파일도 암호화됩니다.
Binlog_cache_use 상태 변수는 스테이트먼트를 저장하기 위해 이 버퍼(및 가능하다면 임시 파일)를 사용한 트랜잭션 수를 보여줍니다. Binlog_cache_disk_use 상태 변수는 실제로 임시 파일을 사용해야 했던 트랜잭션 수를 보여줍니다. 이 두 변수는 임시 파일 사용을 피할 수 있을 만큼 충분히 큰 값으로 binlog_cache_size를 튜닝하는 데 사용할 수 있습니다.
max_binlog_cache_size 시스템 변수(기본값 4GB이며 최대값도 4GB임)는 다중 스테이트먼트 트랜잭션을 캐시하는 데 사용되는 전체 크기를 제한하는 데 사용할 수 있습니다. 트랜잭션이 이 바이트 수보다 크면 실패하고 롤백됩니다. 최소값은 4096입니다.
binary log와 row based logging을 사용하는 경우, CREATE ... SELECT 또는 INSERT ... SELECT 스테이트먼트에 대해서는 동시 삽입(concurrent insert)이 일반 삽입으로 변환됩니다. 이는 백업 작업 중 로그를 적용하여 테이블의 정확한 복사본을 다시 생성할 수 있도록 보장하기 위해 수행됩니다. statement-based logging을 사용하는 경우에는 원래 스테이트먼트가 로그에 기록됩니다.
binary log 포맷에는 백업으로부터 복구에 영향을 줄 수 있는 몇 가지 알려진 제한 사항이 있습니다. Section 19.5.1, “Replication Features and Issues”를 참조하십시오.
스토어드 프로그램에 대한 binary logging은 Section 27.9, “Stored Program Binary Logging”에 설명된 대로 수행됩니다.
binary log 포맷은 복제 향상으로 인해 이전 MySQL 버전과는 MySQL 9.5에서 다르다는 점에 유의하십시오. Section 19.5.2, “Replication Compatibility Between MySQL Versions”를 참조하십시오.
서버가 binary log에 쓸 수 없거나, binary log 파일을 flush하거나, binary log를 디스크에 동기화할 수 없는 경우, 복제 소스 서버의 binary log가 일관성 없게 되고 레플리카가 소스와의 동기화를 잃을 수 있습니다. binlog_error_action 시스템 변수는 binary log에서 이러한 유형의 에러가 발생했을 때 수행할 동작을 제어합니다.
기본 설정인 ABORT_SERVER는 서버가 binary logging을 중단하고 종료하도록 합니다. 이 시점에서 에러의 원인을 식별하고 수정할 수 있습니다. 재시작 시, 복구는 예기치 않은 서버 중지의 경우와 동일한 방식으로 진행됩니다(Section 19.4.2, “Handling an Unexpected Halt of a Replica” 참조).
IGNORE_ERROR 설정은 이전 MySQL 버전과의 하위 호환성을 제공합니다. 이 설정에서는 서버가 진행 중인 트랜잭션을 계속 수행하고 에러를 로그한 다음, binary logging을 중단하지만 업데이트 수행은 계속합니다. 이 시점에서 에러의 원인을 식별하고 수정할 수 있습니다. binary logging을 재개하려면 서버를 재시작하여 log_bin을 다시 활성화해야 합니다. 이 옵션은 하위 호환성이 필요하고, 해당 MySQL 서버 인스턴스에서 binary log가 필수적이지 않을 때만 사용해야 합니다. 예를 들어, binary log를 서버의 간헐적인 감사나 디버깅에만 사용하고, 해당 서버에서 복제를 수행하거나 point-in-time 복구 작업에 의존하지 않는 경우가 이에 해당합니다.
기본적으로 binary log는 각 write마다 디스크에 동기화됩니다(sync_binlog=1). sync_binlog가 활성화되어 있지 않은 상태에서 운영체제나 머신(MySQL 서버 자체뿐만 아니라)이 크래시하는 경우, binary log의 마지막 스테이트먼트가 손실될 수 있습니다.
이를 방지하려면 sync_binlog 시스템 변수를 활성화하여 binary log가 매 N 개의 커밋 그룹마다 디스크에 동기화되도록 하십시오. Section 7.1.8, “Server System Variables”를 참조하십시오. sync_binlog를 위한 가장 안전한 값은 1(기본값)이지만, 이 값이 가장 느리기도 합니다.
이전 MySQL 릴리스에서는, 크래시가 발생한 경우 테이블 내용과 binary log 내용 사이에 불일치가 발생할 가능성이 있었으며, 이는 sync_binlog가 1로 설정된 경우에도 마찬가지였습니다. 예를 들어, InnoDB 테이블을 사용하고 있고 MySQL 서버가 COMMIT 스테이트먼트를 처리할 때, 서버는 다수의 prepared 트랜잭션을 연속적으로 binary log에 기록하고, binary log를 동기화한 다음, 트랜잭션을 InnoDB에 커밋합니다.
서버가 이 두 작업 사이에서 예기치 않게 종료된 경우, 재시작 시 InnoDB에 의해 해당 트랜잭션이 롤백되지만 여전히 binary log에는 남아 있게 됩니다. 이러한 문제는 이전 릴리스에서 XA 트랜잭션의 two-phase commit에 대한 InnoDB 지원을 활성화함으로써 해결되었습니다. MySQL 9.5에서는 XA 트랜잭션에 대한 two-phase commit 지원이 항상 활성화되어 있습니다.
XA 트랜잭션에 대한 InnoDB의 two-phase commit 지원은 binary log와 InnoDB 데이터 파일이 동기화되도록 보장합니다. 그러나 트랜잭션을 커밋하기 전에 binary log와 InnoDB 로그를 디스크에 동기화하도록 MySQL 서버를 구성해야 합니다. InnoDB 로그는 기본적으로 동기화되며, sync_binlog=1은 binary log가 동기화되도록 보장합니다.
XA 트랜잭션에 대한 암묵적인 InnoDB two-phase commit 지원과 sync_binlog=1의 효과는 크래시 이후 재시작 시 롤백을 수행한 후에, MySQL 서버가 최신 binary log 파일을 스캔하여 트랜잭션 xid 값을 수집하고 binary log 파일에서 마지막 유효 위치를 계산한다는 것입니다. 그런 다음 MySQL 서버는 binary log에 성공적으로 기록된 prepared 트랜잭션을 완료하도록 InnoDB에 지시하고, binary log를 마지막 유효 위치까지 잘라냅니다(truncate).
이는 binary log가 InnoDB 테이블의 데이터를 정확히 반영하도록 보장하며, 따라서 롤백된 스테이트먼트를 레플리카가 수신하지 않으므로 레플리카는 소스와의 동기화를 유지하게 됩니다.
MySQL 서버가 크래시 복구 시점에 binary log가 예상보다 짧다는 사실을 발견하면, 적어도 하나의 성공적으로 커밋된 InnoDB 트랜잭션이 누락된 것입니다. sync_binlog=1이고 디스크/파일 시스템이 요청 시 실제로 sync를 수행한다면(일부는 그렇지 않음) 이런 상황은 발생해서는 안 되므로, 서버는 The binary log file_name is shorter than its expected size라는 에러 메시지를 출력합니다.
이 경우, 해당 binary log는 올바르지 않으며 복제는 소스 데이터의 새 스냅샷에서 다시 시작해야 합니다.
다음 시스템 변수의 세션 값은 binary log에 기록되며, 레플리카가 binary log를 파싱할 때 이를 반영합니다:
7.4.3 The General Query Log
7.4.5 The Slow Query Log
