5.2.4 바이너리 로그

바이너리 로그는 테이블 생성 작업과 테이블 데이터의 변경 등의 데이터베이스 변경을 기술하는 "이벤트"가 포함됩니다. 또한 행 기반 로깅이 사용되는 경우를 제외하고 (일치하는 행이없는 DELETE 등) 잠재적으로 변경하려고 한 문에 대한 이벤트도 포함됩니다. 바이너리 로그는 데이터를 업데이트 한 각 문에 걸린 시간에 대한 정보도 포함됩니다. 바이너리 로그에는 두 가지 중요한 목적이 있습니다.

바이너리 로그는 데이터를 변경하지 SELECT 나 SHOW 등의 문은 사용되지 않습니다. (문제가되는 쿼리를 특정하는 등을 위해) 모든 문을 기록하려면 일반 쿼리 로그를 사용합니다. 섹션 5.2.3 "일반 쿼리 로그" 를 참조하십시오.

바이너리 로깅을 활성화하여 서버를 실행하면 성능이 저하됩니다. 그러나 복제를 설정할 수 복원 작업에 대응할 수 있다는 바이너리 로그의 장점은 일반적으로이 성능의 감소보다 중요합니다.

MySQL 5.6.2 이후에서는 바이너리 로그는 충돌 안전되어 있습니다. 전체 이벤트 또는 트랜잭션 만 기록되거나 또는 다시 읽거나합니다.

MySQL 5.6.3 이후에서는 바이너리 로그에 기록되는 문 암호는 서버에 의해 고쳐 쓸 수있어 문자 그대로 일반 텍스트로 표시되는 것은 아닙니다. MySQL 5.6.3 이전에서는 문에서 암호는 고쳐 쓸 수 없기 때문에 바이너리 로그를 보호하도록하십시오. 섹션 6.1.2.3 "암호 및 로깅" 을 참조하십시오.

다음의 설명은 바이너리 로깅의 작동에 영향을 일부 서버 옵션 및 변수에 대해 설명합니다. 전체 목록은 섹션 17.1.4.4 "바이너리 로그 옵션과 변수" 를 참조하십시오.

바이너리 로그를 활성화하려면 --log-bin[= base_name ] 옵션으로 서버를 시작합니다. base_name 값이 지정되지 않은 경우 기본 이름은 pid-file 옵션 값 (기본적으로 이것은 호스트 컴퓨터의 이름) 다음에 -bin 이 계속됩니다. 기본 이름이 지정되는 경우, 다른 디렉토리를 지정하는 절대 경로 이름이 앞에 붙은 기본 이름이 지정되지 않으면 서버는 파일을 데이터 디렉토리에 씁니다. 기본 호스트 이름을 사용하지 않고 기본 이름을 명시 적으로 지정하는 것이 좋습니다. 그 이유에 대해서는 섹션 B.5.8 "MySQL의 알려진 문제" 를 참조하십시오.

로그 이름에 확장자를 지정한 경우 ( --log-bin= base_name.extension 등) 확장은 암시 적으로 삭제되어 무시됩니다.

mysqld는 바이너리 로그 파일명을 생성하기 위해 바이너리 로그베이스 이름에 숫자 확장을 추가합니다. 수치는 서버가 새로운 로그 파일을 만들 때마다 증가 정렬 된 일련의 파일이 생성됩니다. 그 일련의 파일에 새 파일은 서버가 시작하거나 로그를 플러시 할 때마다 서버에서 생성됩니다. 또한 서버는 현재의 로그 크기가 max_binlog_size 에 도달 한 뒤, 새로운 바이너리 로그 파일을 자동으로 만듭니다. 큰 트랜잭션을 사용하는 경우 트랜잭션이 한묶음으로 파일에 기록 된 여러 파일로 분할되지 않기 때문에 바이너리 로그 파일이 max_binlog_size 를 초과 할 수 있습니다.

사용 된 바이너리 로그 파일의 추적을 위해, mysqld는 사용 된 모든 바이너리 로그 파일의 이름을 포함하는 바이너리 로그 인덱스 파일을 만듭니다. 기본적으로 이것은 바이너리 로그 파일과 동일한베이스 이름을 가지고 확장자 '.index' 가 붙어 있습니다. 바이너리 로그 인덱스 파일의 이름은 --log-bin-index[= file_name ] 옵션을 사용하여 변경할 수 있습니다. mysqld가 실행 중일 때이 파일을 수동으로 변경하지 마십시오. 변경하면 mysqld를 혼란시킬 수 있습니다.

"바이너리 로그 파일"이라는 용어는 일반적으로 데이터베이스 이벤트를 저장하는 번호가 지정된 개별 파일을 말합니다. "바이너리 로그"라는 용어는 번호 매기기 된 바이너리 로그 파일과 인덱스 파일 세트를 그룹화 한 것을 말합니다.

SUPER 권한을 가진 클라이언트는 SET sql_log_bin=0 문을 사용하여 자신의 문 바이너리 로깅을 비활성화 할 수 있습니다. 섹션 5.1 "서버 시스템 변수" 를 참조하십시오.

기본적으로 서버는 이벤트 자체뿐만 아니라 이벤트의 길이도 기록하고 이벤트가 제대로 작성되었는지 확인하기 위해 이것을 사용합니다. 또한 binlog_checksum 시스템 변수를 설정하여 서버가 이벤트의 체크섬을 쓰도록 할 수 있습니다. 바이너리 로그에서 읽어 되돌릴 때, 마스터는 기본적으로 이벤트의 길이를 사용하지만 master_verify_checksum 시스템 변수를 사용하여 사용 가능한 체크섬을 사용하도록 변경할 수 있습니다. 슬레이브 I / O thread도 마스터로부터받은 이벤트를 확인합니다. slave_sql_verify_checksum 시스템 변수를 사용하여 릴레이 로그에서 읽을 때 체크섬이 사용 가능한 경우, 슬레이브 SQL 쓰레드가 체크섬을 사용하게 할 수 있습니다.

바이너리 로그에 기록되는 이벤트의 형식은 바이너리 로깅 형식에 따라 달라집니다. 행 기반 로깅, 명령문 기반 로깅 및 혼합 기반 로깅의 3 가지 유형의 형식이 지원됩니다. 사용되는 바이너리 로깅 형식은 MySQL 버전에 따라 달라집니다. 로깅 형식의 일반적인 설명은 섹션 5.2.4.1 "바이너리 로깅 형식" 을 참조하십시오. 바이너리 로그의 형식에 대한 자세한 설명은 " MySQL Internals : The Binary Log "를 참조하십시오.

서버는 --binlog-do-db 및 --binlog-ignore-db 옵션을 평가할 때 그것이 --replicate-do-db 및 --replicate-ignore-db 옵션을 평가하는 것과 동일한 방법으로 합니다. 이렇게하는 방법에 대한 자세한 내용은 섹션 17.2.3.1 "데이터베이스 수준 복제 옵션 및 바이너리 로깅 옵션의 평가" 를 참조하십시오.

리플리케이션 슬레이브 서버는 기본적으로 복제 마스터에서받은 모든 데이터 변경 사항을 자신의 바이너리 로그에 기록하지 않습니다. 이러한 변경 사항을 기록하려면 --log-bin 옵션 이외에 --log-slave-updates 옵션을 지정하고 슬레이브를 시작합니다 ( 섹션 17.1.4.3 "리플리케이션 옵션과 변수" 를 참조하십시오). 그것은 노예가 체인 형 복제 다른 슬레이브 마스터로서의 역할도 경우에 실행됩니다.

RESET MASTER 명령문에서 모든 바이너리 로그 파일을 삭제하거나 PURGE BINARY LOGS 에서 그 일부를 제거 할 수 있습니다. 섹션 13.7.6.6 "RESET 구문」 및 섹션 13.4.1.1 "PURGE BINARY LOGS 구문" 을 참조하십시오.

복제를 사용하는 경우 마스터의 이전 바이너리 로그 파일을 사용할 필요가있다 슬레이브가 없어진 것을 확인하기 전까지는 해당 파일을 삭제하지 않도록하십시오. 예를 들어, 슬레이브가 3 일 이상 늦게 실행될 수없는 경우, mysqladmin flush-logs 마스터에서 1 일 1 회 실행하고 3 일분보다 오래된 로그를 제거 할 수 있습니다. 파일을 수동으로 제거 할 수 있지만, PURGE BINARY LOGS 를 사용하는 것이 좋습니다, 그러면 바이너리 로그 인덱스 파일을 안전하게 업데이트됩니다 (또한 날짜 인수를 사용할 수 있습니다). 섹션 13.4.1.1 "PURGE BINARY LOGS 구문" 을 참조하십시오.

mysqlbinlog 유틸리티를 사용하여 바이너리 로그 파일의 내용을 볼 수 있습니다. 이것은 복구 작업을 위해 로그의 문을 다시 처리 할 때 도움이됩니다. 예를 들어, 다음과 같이 바이너리 로그에서 MySQL Server를 업데이트 할 수 있습니다.

 shell> mysqlbinlog log_file | mysql -h server_name

mysqlbinlog은 리플리케이션 슬레이브 릴레이 로그 파일의 내용을 표시하는 데에도 사용할 수 있습니다. 이것은 이들이 바이너리 로그 파일과 같은 형식을 사용하여 기록되기 때문입니다. mysqlbinlog 유틸리티 및 그 사용 방법에 대한 자세한 내용은 섹션 4.6.8 "mysqlbinlog - 바이너리 로그 파일을 처리하기위한 유틸리티" 를 참조하십시오. 바이너리 로그 및 복구 작업에 대한 자세한 내용은 섹션 7.5 "바이너리 로그를 사용한 시점 (증분) 복구" 를 참조하십시오.

바이너리 로깅은 명령문이나 트랜잭션이 완료된 후 즉시 이루어 지지만 모든 잠금이 출시되거나 커밋이 실행되는 이전됩니다. 이렇게하면 로그가 커밋 순서에 기록되는 것이 보증됩니다.

비 트랜잭션 테이블에 대한 업데이트는 실행 후 곧바로 바이너리 로그에 저장됩니다.

커밋되지 않은 트랜잭션 내에서 InnoDB 테이블 등의 트랜잭션 테이블을 변경하는 모든 업데이트 ( UPDATE , DELETE , INSERT )은 서버에서 COMMIT 문이 받아 질 때까지 캐시됩니다. 그 시점에서 COMMIT 이 실행되기 전에 mysqld는 전체 트랜잭션을 바이너리 로그에 기록합니다.

비 트랜잭션 테이블의 변경 내용은 롤백 할 수 없습니다. 롤백되는 트랜잭션에 비 트랜잭션 테이블에 변경 사항이 포함되어있는 경우는 비 트랜잭션 테이블에 변경이 확실히 복제되도록하기 위해 마지막으로 ROLLBACK 문을 사용하여 전체 트랜잭션 로그 에 기록됩니다.

트랜잭션을 처리하는 스레드가 시작되면 스레드는 binlog_cache_size 버퍼를 버퍼 명령문에 할당합니다. 문이 더 큰 경우 스레드는 트랜잭션을 저장할 임시 파일을 엽니 다. 스레드가 종료되면 임시 파일은 삭제됩니다.

Binlog_cache_use 상태 변수는 명령문을 저장하기 위해이 버퍼 (및 경우에 따라서는 임시 파일)를 사용한 트랜잭션의 수를 표시합니다. Binlog_cache_disk_use 상태 변수는이 트랜잭션 중 실제로 임시 파일을 사용할 필요가 있던 무슨 수를 표시합니다. 이러한 두 변수는 임시 파일 사용을 피하기 위해 충분한 값이되도록 binlog_cache_size 을 조정하는 데 사용할 수 있습니다.

max_binlog_cache_size 시스템 변수 (기본값은 최대의 4G 바이트)를 사용하여 여러 명령문 트랜젝션을 캐시하는 데 사용되는 전체 크기를 제한 할 수 있습니다. 트랜잭션이이 바이트 수보다 커지면 실패하고 롤백합니다. 최소값은 4096입니다.

바이너리 로그 및 행 기반 로깅을 사용하는 경우 병렬 삽입은 CREATE ... SELECT 또는 INSERT ... SELECT 문 일반적인 삽입으로 변환됩니다. 이것은 백업 조작 중에 로그를 적용하여 테이블의 정확한 복사본을 확실하게 다시 만들 수 있도록하기 위해 이루어집니다. 명령문 기반 로깅을 사용하는 경우 원래의 문이 로그에 기록됩니다.

바이너리 로그에는 백업에서 복구에 영향을 미칠 수있는 몇 가지 알려진 제한이 있습니다. 섹션 17.4.1 "복제 기능 및 문제" 를 참조하십시오.

저장 프로그램의 바이너리 로깅은 섹션 20.7 "저장 프로그램의 바이너리 로깅" 에서 설명한대로 이루어집니다.

MySQL 5.6의 바이너리 로그 형식은 복제 기능을 통해 이전 버전의 MySQL과는 다르다는 점에 유의하십시오. 섹션 17.4.2 "MySQL 버전 간의 복제 호환성" 을 참조하십시오.

바이너리 로그 파일 및 바이너리 로그 인덱스 파일에 쓰기는 MyISAM 테이블에 쓰기와 같은 방법으로 처리됩니다. 섹션 B.5.4.3 "MySQL이 가득 찬 디스크를 처리하는 방법" 을 참조하십시오.

기본적으로 바이너리 로그는 매번 쓰기마다 디스크와 동기화되는 것은 아닙니다. 따라서 (MySQL Server뿐만 아니라) 운영 체제 또는 시스템이 충돌 한 경우 바이너리 로그의 마지막 문이 손실 될 수 있습니다. 이를 방지하려면 sync_binlog 시스템 변수를 사용하여 N 개의 커밋 그룹이 끝나면마다 바이너리 로그를 디스크에 동기화합니다. 섹션 5.1 "서버 시스템 변수" 를 참조하십시오. 가장 안전한 sync_binlog 의 값은 1이며, 가장 느린 값이기도합니다. sync_binlog 을 1로 설정되었다고해도 충돌시에 테이블의 내용과 바이너리 로그의 내용 사이에 불일치가 발생할 수 있습니다.

예를 들어, InnoDB 테이블을 사용하고 MySQL Server가 COMMIT 문을 처리하는 경우 MySQL Server는 생성 된 많은 트랜잭션을 바이너리 로그에 차례로 기입 바이너리 로그를 동기화 다음이 트랜잭션을 InnoDB 에 커밋 합니다. 이러한 두 가지 작업을 처리하는 동안 서버가 충돌하면이 트랜잭션은 다시 시작할 때 InnoDB 에 의해 롤백되지만 바이너리 로그에 아직 존재합니다. 이러한 문제는 --innodb_support_xa 가 기본 1로 설정되어 있다고 가정하면 해결됩니다. 이 옵션은 InnoDB의 XA 트랜잭션 지원과 관련 있지만,이 옵션은 바이너리 로그와 InnoDB 데이터 파일이 동기화되는 것을 보장합니다. 이 옵션은 더 높은 안전성이 제공되도록하기 위해 MySQL Server는 트랜잭션을 커밋하기 전에 바이너리 로그와 InnoDB 로그를 디스크에 동기화하도록 구성되도록합니다. InnoDB 로그는 기본적으로 동기화되므로 바이너리 로그를 동기화하기 위해 sync_binlog=1 을 사용 할 수 있습니다. 이 옵션의 영향은 충돌 후 다시 시작할 때 트랜잭션 롤백을 수행 한 후 MySQL Server는 롤백 된 InnoDB 트랜잭션을 바이너리 로그에서 제거하는 것입니다. 따라서 바이너리 로그는 InnoDB 테이블의 정확한 데이터를 반영하고 따라서 슬레이브는 롤백 된 문을받지 않기 때문에 마스터와 동기화 된 상태가 유지됩니다.

바이너리 로그가 필요한 길이보다 짧다는 것을, MySQL Server 충돌 복구 중에 발견 한 경우 성공적으로 커밋 된 InnoDB 트랜잭션이 하나 바이너리 로그에서 누락 된 것을 보여줍니다. 이것은 sync_binlog=1 의 경우가 발생 할 리가없고, 디스크 또는 파일 시스템은 요청 된 경우 (되지 않는 경우도 있습니다) 실제 동기화를 수행하는 서버는 「The binary log file_name is shorter than its expected size」 라는 오류 메시지를 출력합니다. 이 경우,이 바이너리 로그는 잘못되어 마스터 데이터의 신선한 스냅 샷에서 복제를 다시 시작하도록하십시오.

다음 시스템 변수 세션 값은 바이너리 로그에 기록되고 바이너리 로그를 구문 분석 할 때 리플리케이션에 의해 허용됩니다.