MySQL 5.6 한글메뉴얼

5.2.4.3 혼합 형식의 바이너리 로깅 형식

MIXED 로깅 형식으로 실행하면 서버는 다음과 같은 경우에 명령문 기반 로깅에서 행 기반 로깅로 자동 전환합니다.

함수에 UUID() 이 포함되어있는 경우. f
AUTO_INCREMENT 컬럼을 포함하는 하나 이상의 테이블이 업데이트되며, 트리거 또는 스토어드 함수가 불려 갔을 때. 다른 모든 안전하지 않은 문처럼 binlog_format = STATEMENT 의 경우 이로 인해 경고가 생성됩니다.

자세한 내용은 섹션 17.4.1.1 "복제 및 AUTO_INCREMENT" 를 참조하십시오.
뷰의 본체가 행 기반 복제를 필요로 할 때 뷰를 작성하는 문도 그것을 사용할 때. 예를 들어, 뷰를 생성하는 문이 UUID() 함수를 사용할 때 발생합니다.
UDF 호출이 포함 된 경우.
비 트랜잭션 테이블에 대해 INSERT DELAYED 가 실행될 때.
문이 행마다 기록되어 문을 실행 한 세션이 하나의 임시 테이블을 가지는 경우, 그 세션에서 사용중인 모든 임시 테이블이 삭제 될 때까지 이후의 모든 문에서 행마다 로깅이 사용됩니다 (임시 테이블에 액세스하는 문을 제외).

이것은 하나의 임시 테이블이 실제로 기록되는 여부에 관계없이 적용됩니다.

행 기반 형식을 사용하여 임시 테이블을 기록 할 수 없기 때문에 행 기반 로깅이 사용되면 그 테이블을 사용하는 모든 후속 문은 안전하지 않습니다. 세션이 임시 테이블을 유지하지 않을 때까지 서버는 세션에서 실행되는 모든 문을 처리하여이 상황을 안전하지 않은 것으로 추정합니다.
FOUND_ROWS() 또는 ROW_COUNT() 가 사용되는 때. (Bug # 12092, Bug # 30244)
USER() , CURRENT_USER() 또는 CURRENT_USER 가 사용되는 때. (Bug # 28086)
문이 하나 이상의 시스템 변수를 참조 할 때. (Bug # 31168)

예외 다음의 시스템 변수가 세션 범위 (전용)에서 사용 된 경우 로깅 형식 전환은 발생하지 않습니다.
- auto_increment_increment
- auto_increment_offset
- character_set_client
- character_set_connection
- character_set_database
- character_set_server
- collation_connection
- collation_database
- collation_server
- foreign_key_checks
- identity
- last_insert_id
- lc_time_names
- pseudo_thread_id
- sql_auto_is_null
- time_zone
- timestamp
- unique_checks
시스템 변수 범위를 결정하는 내용은 섹션 5.1.5 "시스템 변수 사용" 을 참조하십시오.

복제가 sql_mode 를 처리하는 방법은 섹션 17.4.1.34 "복제 및 변수" 를 참조하십시오.
관련된 테이블 중 하나가 mysql 데이터베이스의 로그 테이블의 때.
LOAD_FILE() 함수가 사용되는 때. (Bug # 39701)

참고

행 기반 로깅을 사용하여 작성되어야 문을 명령문 기반 로깅을 사용하여 실행하려고하면 경고가 생성됩니다. 경고는 클라이언트 ( SHOW WARNINGS 의 출력에서) 및 mysqld 오류 로그 모두에 표시됩니다. 그런 문이 실행될 때마다 경고가 SHOW WARNINGS 테이블에 추가됩니다. 그러나 로그가 가득되는 것을 방지하기 위해 각 클라이언트 세션에 대해 경고를 생성 한 첫 번째 문만 오류 로그에 기록됩니다.

위의 판단 외에 테이블의 정보가 업데이트 될 때 사용되는 로깅 형식이 개별 엔진에 의해 결정되는 경우도 있습니다. 개별 엔진의 로깅 기능은 다음과 같이 정의 할 수 있습니다.

엔진이 행 기반 로깅을 지원하는 경우, 그 엔진은 행 로깅 대응이라고합니다.
엔진이 명령문 기반 로깅을 지원하는 경우, 그 엔진은 문 로깅 대응이라고합니다.

특정 스토리지 엔진 중 하나 또는 모두 로깅 형식을 지원할 수 있습니다. 다음 표에서는 각 엔진에서 지원하는 형식을 나타냅니다.

스토리지 엔진	행 로깅 지원	문 로깅 지원
`ARCHIVE`	예	예
`BLACKHOLE`	예	예
`CSV`	예	예
`EXAMPLE`	예	아니오
`FEDERATED`	예	예
`HEAP`	예	예
`InnoDB`	예	트랜잭션 격리 수준이 `REPEATABLE READ` 또는 `SERIALIZABLE` 의 경우 "예", 그렇지 않으면 "아니오."
`MyISAM`	예	예
`MERGE`	예	예
`NDB`	예	아니오

MySQL 5.6에서는 문이 기록되는지 여부와 사용되는 로깅 모드는 문 유형 (안전 안전하지 않은 또는 바이너리 인젝션) 바이너리 로깅 형식 ( STATEMENT , ROW 또는 MIXED ) 및 스토리지 엔진의 로깅 기능 (문 대응 행 대응 모두 또는 하나가 아니다)에 따라 결정됩니다. (바이너리 인젝션은 ROW 형식을 사용하여 기록 할 필요가있는 변경 사항을 로그를 의미합니다.)

문이 기록 될 때 경고를내는 경우와 내지 않는 경우가 있습니다. 실패한 명령문은 기록되지 않지만 로그에 오류가 생성됩니다. 이것을 다음 결정 테이블입니다. 여기에서 SLC는 "문 로깅 대응"을 나타내고, RLC는 "행 로깅 대응"을 말합니다.

조건				액션
유형	`binlog_format`	SLC	RLC	오류 또는 경고	로깅 형식
*	`*`	아니오	아니오	Error : Can not execute statement : 행 기록에도 문 로깅을 지원하지 않는 엔진이 하나 있기 때문에 바이너리 로깅은 불가능합니다.	`-`
안전	`STATEMENT`	예	아니오	-	`STATEMENT`
안전	`MIXED`	예	아니오	-	`STATEMENT`
안전	`ROW`	예	아니오	Error : Can not execute statement : `BINLOG_FORMAT = ROW` 이며, 적어도 하나의 테이블이 행 기반 로깅을 지원하지 않는 스토리지 엔진을 사용하고 있기 때문에 바이너리 로깅은 불가능합니다.	`-`
안전하지 않은	`STATEMENT`	예	아니오	Warning : Unsafe statement binlogged in statement format : `BINLOG_FORMAT = STATEMENT` 이기 때문에.	`STATEMENT`
안전하지 않은	`MIXED`	예	아니오	Error : Can not execute statement : `BINLOG_FORMAT = MIXED` 에도 스토리지 엔진이 명령문 기반 로깅에 한정되어있는 경우 안전하지 않은 문 바이너리 로깅은 불가능합니다.	`-`
안전하지 않은	`ROW`	예	아니오	Error : Can not execute statement : `BINLOG_FORMAT = ROW` 이며, 적어도 하나의 테이블이 행 기반 로깅을 지원하지 않는 스토리지 엔진을 사용하고 있기 때문에 바이너리 로깅은 불가능합니다.	-
행 삽입	`STATEMENT`	예	아니오	Error : Can not execute row injection : 하나의 테이블이 행 기반 로깅을 지원하지 않는 스토리지 엔진을 사용하고 있기 때문에 바이너리 로깅은 불가능합니다.	-
행 삽입	`MIXED`	예	아니오	Error : Can not execute row injection : 하나의 테이블이 행 기반 로깅을 지원하지 않는 스토리지 엔진을 사용하고 있기 때문에 바이너리 로깅은 불가능합니다.	-
행 삽입	`ROW`	예	아니오	Error : Can not execute row injection : 하나의 테이블이 행 기반 로깅을 지원하지 않는 스토리지 엔진을 사용하고 있기 때문에 바이너리 로깅은 불가능합니다.	-
안전	`STATEMENT`	아니오	예	Error : Can not execute statement : `BINLOG_FORMAT = STATEMENT` 이며, 적어도 하나의 테이블이 명령문 기반 로깅을 지원하지 않는 스토리지 엔진을 사용하고 있기 때문에 바이너리 로깅은 불가능합니다.	`-`
안전	`MIXED`	아니오	예	-	`ROW`
안전	`ROW`	아니오	예	-	`ROW`
안전하지 않은	`STATEMENT`	아니오	예	Error : Can not execute statement : `BINLOG_FORMAT = STATEMENT` 이며, 적어도 하나의 테이블이 명령문 기반 로깅을 지원하지 않는 스토리지 엔진을 사용하고 있기 때문에 바이너리 로깅은 불가능합니다.	-
안전하지 않은	`MIXED`	아니오	예	-	`ROW`
안전하지 않은	`ROW`	아니오	예	-	`ROW`
행 삽입	`STATEMENT`	아니오	예	Error : Can not execute row injection : `BINLOG_FORMAT = STATEMENT` 때문에 바이너리 로깅은 불가능합니다.	`-`
행 삽입	`MIXED`	아니오	예	-	`ROW`
행 삽입	`ROW`	아니오	예	-	`ROW`
안전	`STATEMENT`	예	예	-	`STATEMENT`
안전	`MIXED`	예	예	-	`STATEMENT`
안전	`ROW`	예	예	-	`ROW`
안전하지 않은	`STATEMENT`	예	예	Warning : Unsafe statement binlogged in statement format : `BINLOG_FORMAT = STATEMENT` 이기 때문에.	`STATEMENT`
안전하지 않은	`MIXED`	예	예	-	`ROW`
안전하지 않은	`ROW`	예	예	-	`ROW`
행 삽입	`STATEMENT`	예	예	Error : Can not execute row injection : `BINLOG_FORMAT = STATEMENT` 때문에 바이너리 로깅은 불가능합니다.	-
행 삽입	`MIXED`	예	예	-	`ROW`
행 삽입	`ROW`	예	예	-	`ROW`

결정에 의해 경고가 생성되는 경우 표준 MySQL 경고가 생성됩니다 (경고는 SHOW WARNINGS 을 사용하여 확인할 수 있습니다.) 이 정보는 mysqld 오류 로그에 기록됩니다. 로그가 가득 차면 것을 방지하기 위해 오류는 각 클라이언트 연결 오류 발생에 대해 하나 기록됩니다. 로그 메시지에는 시도 된 SQL 문이 포함됩니다.

슬레이브 서버가 --log-warnings 를 사용하여 실행 된 경우, 슬레이브는 슬레이브의 상태에 대한 정보를 제공하기위한 메시지를 오류 로그에 출력하고,이 정보는 슬레이브가 작업을 시작했을 때 바이너리 로그와 릴레이 로그의 좌표 다른 릴레이 로그로 전환시기, 절단 후 재 연결하는시기 등이 있습니다.