--binlog-row-event-max-size = N

행 기반의 바이너리 로그 이벤트의 최대 크기를 바이트 단위로 지정합니다. 가능하면 행이 크기보다 작은 이벤트로 그룹화됩니다. 값은 256의 배수 여야합니다. 기본값은 MySQL 5.6.6 이후에서는 8192 그 이전에는 1024입니다. 섹션 17.1.2 "복제 형식" 을 참조하십시오.

--log-bin [= base_name ]

바이너리 로깅을 활성화합니다. 서버는 데이터를 변경하는 모든 명령문의 로그를 바이너리 로그에 기록하고 이것은 백업 및 복제에 사용됩니다. 섹션 5.2.4 "바이너리 로그" 를 참조하십시오.

옵션 값 (지정된 경우)는 로그 시퀀스의 기본 이름입니다. 서버는 기본 이름에 숫자 접미사를 추가하여 바이너리 로그 파일을 계속해서 만듭니다. 기본 이름을 지정하는 것이 좋습니다 (그 이유는 섹션 B.5.8 "MySQL의 알려진 문제" 를 참조하십시오). 그렇지 않은 경우, MySQL은 기본 이름으로 host_name -bin 을 사용합니다.

MySQL 5.6.5 이후 서버는 인덱스 파일에서 항목을 읽을 때 항목에 상대 경로가 포함되어 있는지 여부를 확인하고, 그런 경우는 경로의 상대 부가 --log-bin 옵션을 사용하여 설정된 절대 경로로 대체합니다. 절대 경로는 바뀌지 않습니다. 이러한 경우 사용되는 새로운 경로를 활성화하기 위해 인덱스를 수동으로 편집해야합니다. MySQL 5.6.5 이전에는 바이너리 로그 또는 릴레이 로그 파일의 위치를​​ 변경하는 경우에는 수동 개입이 필요했습니다. (Bug # 11745230, Bug # 12133)

이 옵션을 설정함으로써 log_bin 시스템 변수는 ON (또는 1 )로 설정됩니다 (기본 이름이 아니라). MySQL 5.6.2 이후에서는 바이너리 로그 파일 이름 (경로 포함)은 log_bin_basename 시스템 변수로 사용할 수 있습니다.

--log-bin-index [= file_name ]

바이너리 로그 파일명의 인덱스 파일. 섹션 5.2.4 "바이너리 로그" 를 참조하십시오. 파일 이름을 지정하지 않으면 및 --log-bin 에서이를 지정하지 않으면, MySQL은 파일 이름으로 host_name -bin.index 을 사용합니다.

--log-bin-trust-function-creators [= {0 | 1}]

이 옵션은 해당 log_bin_trust_function_creators 시스템 변수를 설정합니다. 인수가 지정되지 않은 경우,이 옵션은 변수를 1로 설정합니다. log_bin_trust_function_creators 는 스토어드 함수 및 트리거 만들기에 MySQL이 어떻게 제한을 적용할지에 영향을줍니다. 섹션 20.7 "저장 프로그램의 바이너리 로깅" 을 참조하십시오.

--log-bin-use-v1-row-events [= {0 | 1}]

버전 2 바이너리 로그 행 이벤트를 MySQL 5.6.6 이상에서 사용할 수 있습니다. 그러나 버전 2 이벤트는 이전의 MySQL Server 릴리스에서 읽을 수 없습니다. 이 옵션을 1로 설정하면 mysqld는 버전 1 로깅 이벤트 (이것은 이전 버전에서 사용되는 바이너리 로그 이벤트의 유일한 버전)를 사용하여 바이너리 로그를 쓰기 이전 슬레이브에서 읽을 바이너리 로그를 생성합니다. --log-bin-use-v1-row-events 를 0 (기본값)로 설정하면 mysqld는 버전 2 바이너리 로그 이벤트를 사용합니다.

이 옵션에 사용되는 값은 읽기 전용 log_bin_use_v1_row_events 시스템 변수에서 얻을 수 있습니다.

--log-bin-use-v1-row-events 주로 NDB$EPOCH_TRANS() (버전 2 바이너리 로그 행 이벤트가 필요)를 충돌 감지 기능으로 사용하여 복제 충돌 감지 및 해결을 설정할 때 도움이됩니다. 따라서이 옵션과 --ndb-log-transaction-id 는 호환되지 않습니다.

자세한 내용은 섹션 18.6.11 "MySQL Cluster 복제 충돌 해결" 을 참조하십시오.

--log-short-format

바이너리 로그와 슬로우 쿼리 로그가 활성화되어있는 경우 이러한 로그 정보를 적게합니다.

--binlog-do-db = db_name

이 옵션은 --replicate-do-db 복제에 영향을뿐만 아니라 바이너리 로깅에 영향을줍니다.

이 옵션의 영향은 명령문 기반 또는 행 기반 로깅 형식의 어느 쪽이 사용되는지에 따라 달라집니다 ( --replicate-do-db 의 영향이 명령문 기반 또는 열 기반 리플리케이션의 어느 쪽이 사용되었는지에 의존하는 것과 같은) . 지정된 문을 기록하는 데 사용되는 형식이 binlog_format 값으로 나타나는 형식과 반드시 동일하지 않다는 것을 명심하십시오. 예를 들어, CREATE TABLE 또는 ALTER TABLE 같은 DDL 문은 활성화되어있는 로깅 형식에 관계없이 항상 문으로 로그가 기록되기 때문에 --binlog-do-db 의 다음 명령문 기반 규칙은 문 로그가 기록되는지 여부의 판단에 항상 적용됩니다.

명령문 기반 로깅 기본 데이터베이스 (즉, USE 에서 선택된 것)가 db_name 인 문 만이 바이너리 로그에 기록됩니다. 여러 데이터베이스를 지정하려면이 옵션을 여러 번 (데이터베이스마다 1 회) 사용합니다. 그러나 이렇게해도 다른 데이터베이스가 선택되어있을 때 (또는 데이터베이스가 선택되지 않은 경우)에 UPDATE some_db.some_table SET foo='bar' 등의 데이터베이스 간 문의 로그는 기록되지 않습니다.

명령문 기반 로깅을 사용할 때 예상되는 기능 예제 : 서버가 --binlog-do-db=sales 로 시작되는 다음 명령문을 발행하는 경우 UPDATE 문 로그는 기록되지 않습니다.

 USE prices;
 UPDATE sales.january SET amount = amount + 1000;

이 "기본 데이터베이스를 확인 만"동작의 주된 이유는 문만에서 복제해야하는지 여부를 알 수 어렵습니다 (예를 들어, 여러 데이터베이스에 걸쳐 작동하는 여러 테이블 DELETE 문 이상의 테이블 UPDATE 문 를 사용하는 경우). 또한 필요가없는 경우 모든 데이터베이스가 아니라 기본 데이터베이스 만 확인하는 것이 빠릅니다.

또 다른 케이스는 자명하지 않을지도 모르지만, 옵션을 설정할 때 지정된 않았더라도 소정의 데이터베이스가 복제됩니다. 서버가 --binlog-do-db=sales 로 시작되는 경우 --binlog-do-db 설정시 prices 이 포함되지 않았다하더라도 다음 UPDATE 문이 기록됩니다.

          
 USE sales;
 UPDATE prices.discounts SET percentage = percentage +10;

UPDATE 문이 발행 된 경우 sales 기본 데이터베이스이기 때문에 UPDATE 가 기록됩니다.

행 기반 로깅 로깅 데이터베이스 db_name 제한됩니다. db_name 에 속하는 테이블에 변경 사항 만 기록됩니다. 기본 데이터베이스는 이에 영향을주지 않습니다. 서버가 --binlog-do-db=sales 로 시작되어 행 기반 로깅이 유효하다고 가정하면 다음 명령문이 실행됩니다.

 USE prices;
 UPDATE sales.february SET amount = amount + 100;

sales 데이터베이스의 february 테이블에 변경이 UPDATE 문에 따라 기록됩니다. 이것은 USE 문이 실행되었는지 여부에 관계없이 발생합니다. 그러나 행 기반 로깅 형식 및 --binlog-do-db=sales 를 사용할 때는 다음 UPDATE 에 의해 변경된 로그는 기록되지 않습니다.

 USE prices;
 UPDATE prices.march SET amount = amount-25;

USE prices 문이 USE sales 에 변경된 경우에도 UPDATE 문의 결과는 여전히 바이너리 로그에 기록되지 않습니다.

--binlog-do-db 처리에 명령문 기반 로깅 및 행 기반 로깅 간의 또 다른 중요한 차이점은 여러 데이터베이스를 참조하는 명령문에 대해 발생합니다. 서버가 --binlog-do-db=db1 에 시작되어 다음 명령문이 실행된다고 가정합니다.

 USE db1;
 UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

명령문 기반 로깅을 사용하는 경우 두 테이블에 업데이트가 바이너리 로그에 기록됩니다. 한편, 행 기반 형식을 사용할 때 table1 에 대한 변경 사항 만 기록됩니다. table2 는 다른 데이터베이스에 있으며 UPDATE 에 의해 변경되지 않습니다. 여기에서 USE db1 문 대신 USE db4 문이 사용 된 것으로합니다.

 USE db4;
 UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

이 경우 명령문 기반 로깅을 사용할 때 UPDATE 문은 바이너리 로그에 기록되지 않습니다. 한편, 행 기반 로깅을 사용할 때 table1 에 변경 로그는 기록되지만, table2 에 그렇게되지 않습니다. 즉, --binlog-do-db 의해 지정된 데이터베이스의 테이블에 변경 사항 만 기록되어 기본 데이터베이스의 선택은이 동작에 영향을주지 않습니다.

--binlog-ignore-db = db_name

이 옵션은 --replicate-ignore-db 복제에 영향을 줄 이진 로깅에 영향을줍니다.

이 옵션의 영향은 명령문 기반 또는 행 기반 로깅 형식의 어느 쪽이 사용되는지에 따라 달라집니다 ( --replicate-ignore-db 의 영향이 명령문 기반 또는 열 기반 리플리케이션의 어느 쪽이 사용되었는지에 의존하는 것과 같은) . 지정된 문을 기록하는 데 사용되는 형식이 binlog_format 값으로 나타나는 형식과 반드시 동일하지 않다는 것을 명심하십시오. 예를 들어, CREATE TABLE 또는 ALTER TABLE 같은 DDL 문은 활성화되어있는 로깅 형식에 관계없이 항상 문으로 로그가 기록되기 때문에 --binlog-ignore-db 의 다음 명령문 기반 규칙은 문 로그가 기록되는지 여부의 판단에 항상 적용됩니다.

명령문 기반 로깅 기본 데이터베이스 (즉, USE 에서 선택된 것)가 db_name 인 문을 기록하지 않도록 서버에 지시합니다.

MySQL 5.6.12 이전에는이 ​​옵션은 기본 데이터베이스가 지정되지 않은 경우 (즉, SELECT DATABASE() 가 NULL 을 반환하는 경우)는 정규화 된 테이블 이름을 포함 문을 기록하지 않습니다 줘 했다. MySQL 5.6.12 이후 버전에서는 기본 데이터베이스가없는 경우에는 --binlog-ignore-db 옵션은 적용되지 않고, 항상 같은 문이 기록됩니다. (Bug # 11829838, Bug # 60188)

행 기반 형식 데이터베이스 db_name 에있는 테이블에 대한 업데이트를 기록하지 않도록 서버에 지시합니다. 현재 데이터베이스에는 영향을주지 않습니다.

명령문 기반 로깅을 사용할 때 다음 예제는 예상 한대로 작동하지 않습니다. 서버가 --binlog-ignore-db=sales 로 시작되는 다음 명령문을 발행한다고 가정합니다.

 USE prices;
 UPDATE sales.january SET amount = amount + 1000;

--binlog-ignore-db 가 기본 데이터베이스 ( USE 문에서 결정)에만 적용되기 때문에 이런 경우 UPDATE 문이 기록됩니다. sales 데이터베이스가 문에서 명시 적으로 지정된 때문에 문은 필터링되지 않았습니다. 한편, 행 기반 로깅을 사용하는 경우에는 UPDATE 문의 결과는 바이너리 로그에 기록되지 않으며 이것은 sales.january 테이블의 변경 내용이 기록되지 않는 것을 의미합니다. 이 예에서는 --binlog-ignore-db=sales 에 의해 마스터 sales 데이터베이스 복사본의 테이블에 추가 한 모든 변경이 바이너리 로깅이 무시됩니다.

무시하는 데이터베이스를 여러 개 지정하려면이 옵션을 여러 번 (데이터베이스마다 1 회) 사용합니다. 데이터베이스 이름에 쉼표를 포함 할 수 있기 때문에 쉼표로 구분 된 목록을 지정하면 목록은 단일 데이터베이스의 이름으로 처리됩니다.

크로스 데이터베이스 업데이트를 사용하고, 그 업데이트 로그를 기록하지 않으려면이 옵션을 사용하지 마십시오.

--binlog-checksum = {NONE | CRC32}

이 옵션을 사용하여 마스터 바이너리 로그에 기록되는 이벤트의 체크섬을 씁니다. NONE 으로 설정하면 비활성화되고 그렇지 않으면 알고리즘의 이름을 사용하여 체크섬이 생성됩니다. 현재 CRC32 체크섬 만 지원됩니다. MySQL 5.6.6 이후에서는 CRC32이 기본입니다.

이 옵션은 MySQL 5.6.2에서 추가되었습니다.

--master-verify-checksum = {0 | 1}

이 옵션을 사용하여 마스터는 체크섬을 사용하여 바이너리 로그에서 이벤트를 확인하고 일치하지 않으면 오류로 중지합니다. 기본적으로 비활성화되어 있습니다.

이 옵션은 MySQL 5.6.2에서 추가되었습니다.

--max-binlog-dump-events = N

이 옵션은 복제 테스트 및 디버깅을 위해 MySQL 테스트 스위트에서 내부적으로 사용됩니다.

--sporadic-binlog-dump-fail

이 옵션은 복제 테스트 및 디버깅을 위해 MySQL 테스트 스위트에서 내부적으로 사용됩니다.

--binlog-rows-query-log-events

이 옵션은 MySQL 5.6.2에서 추가 된 binlog_rows_query_log_events 을 사용합니다. MySQL 5.6.1 이전의 슬레이브 서버 또는 mysqlbinlog 버전에 대한 로그를 생성 할 때는 OFF (기본값)로 설정해야합니다.

binlog_cache_size

트랜잭션 중에 바이너리 로그에 변경 내용을 유지하는 캐시의 크기. 서버가 트랜잭션 스토리지 엔진을 지원하고 서버의 바이너리 로그가 활성화 ( --log-bin 옵션)가있는 경우, 바이너리 로그 캐시가 각 클라이언트에 할당됩니다. 큰 트랜잭션을 자주 사용하는 경우 성능 향상을 위해 캐시 크기를 늘릴 수 있습니다. Binlog_cache_use 와 Binlog_cache_disk_use 상태 변수는이 변수의 크기를 조정하는 데 도움이 될 수 있습니다. 섹션 5.2.4 "바이너리 로그" 를 참조하십시오.

binlog_cache_size 는 트랜잭션 캐시 만의 크기를 설정합니다. 문 캐시의 크기는 binlog_stmt_cache_size 시스템 변수에 의해 관리됩니다.

binlog_checksum

이 변수가 활성화되면 마스터는 바이너리 로그에 각 이벤트의 체크섬을 씁니다. binlog_checksum 값 NONE (무효) 및 CRC32 를 지원합니다. 기본값은 MySQL 5.6.6 이후에서는 CRC32 , 이전은 NONE 입니다.

binlog_checksum 이 무효 (값 NONE )의 경우, 서버는 각 이벤트의 이벤트 길이 (체크섬이 아닌)을 쓰고 체크하여 다 모여 이벤트만을 바이너리 로그에 기록한다는 사실을 확인합니다.

이 변수의 값을 변경하면 바이너리 로그를 순환합니다. 체크섬은 항상 바이너리 로그 파일 전체에 (그 일부만이 아니라) 기록됩니다.

이 변수는 MySQL 5.6.2에서 추가되었습니다.

MySQL 5.6.6 이후에서는 마스터에서이 변수를 슬레이브로 인식되지 않는 값으로 설정하면 슬레이브는 자신의 binlog_checksum 값을 NONE 으로 설정하고 복제 오류에서 중지합니다. (Bug # 13553750, Bug # 61096) 오래된 슬레이브와의 호환성이 우려되는 경우는 명시 적으로 값을 NONE 으로 설정하는 것이 좋습니다.

binlog_direct_non_transactional_updates

트랜잭션 테이블과 비 트랜잭션 테이블 모두에 대한 업데이트가 트랜잭션에 포함될 때 병렬 문제로 인해 노예가 불일치가 발생할 수 있습니다. MySQL은 비 트랜잭션 문을 트랜잭션 캐시에 작성하여 (위탁시에 플래시된다) 이러한 문 사이의 인과 관계를 유지하려고합니다. 그러나 트랜잭션 대신 비 트랜잭션 테이블에 변경 사항이 다른 연결에 즉시 표시 될 때 문제가 발생합니다 (이러한 변경 사항이 즉시 바이너리 로그에 기록되지 않을 수 있기 때문에).

binlog_direct_non_transactional_updates 변수는이 문제에 대한 하나의 가능한 해결 방법을 제공합니다. 기본적으로이 변수는 사용할 수 없습니다. binlog_direct_non_transactional_updates 를 사용하여 비 트랜잭션 테이블에 업데이트가 트랜잭션 캐시가 아닌 직접 바이너리 로그에 기록됩니다.

binlog_direct_non_transactional_updates 는 명령문 기반 바이너리 로깅 형식을 사용하여 복제되는 문에만 작동합니다. 즉, binlog_format 값이 STATEMENT 때 또는 binlog_format 이 MIXED 에서 주어진 문이 문 기반 형식을 사용하여 복제 된 경우에만 작동합니다. 바이너리 로그 형식이 ROW 때 또는 binlog_format 이 MIXED 로 설정되어 주어진 문이 행 기반 형식으로 복제 될 때,이 변수는 효과가 없습니다.

MySQL 5.6에서는 바이너리 로그 형식이 ROW 또는 MIXED 때,이 변수는 효과가 없습니다. (Bug # 51291)

binlog_error_action

서버가 바이너리 로그에 기록 째 없을 때 (마스터 로그가 불일치하게 리플리케이션 슬레이브가 동기를 잃을 수있다)에 무슨 일이 일어날지를 제어합니다. 이전 릴리스에서는 이름 binlogging_impossible_mode 를 사용했습니다.

MySQL 5.6에서는 binlog_error_action 의 기본은 IGNORE_ERROR 에서 서버가 오류를 기록하고 로깅을 중지하고 업데이트를 계속 실행하는 것을 의미합니다. 이것은 이전 버전의 MySQL Server와의 호환성을 제공하기 때문입니다. 이 변수를 ABORT_SERVER 로 설정하면 서버가 바이너리 로그에 기록 할 수없는 경우 로깅을 중지하고 종료합니다. 이것이 권장되는 설정입니다 (특히 복잡한 복제 환경에서).

binlog_format

이 변수는 바이너리 로깅 형식을 설정하고 STATEMENT , ROW , MIXED 중 하나가 가능합니다. 섹션 17.1.2 "복제 형식" 을 참조하십시오. binlog_format 은 시작할 때 --binlog-format 옵션 또는 런타임에 binlog_format 변수로 설정됩니다.

MySQL 5.6에서는 기본 형식은 STATEMENT 입니다. 예외 : MySQL Cluster NDB 7.3 이상에서는 디폴트는 MIXED 입니다. 문 기반 복제는 MySQL Cluster는 지원되지 않습니다.

글로벌 또는 세션 binlog_format 값을 설정하려면 SUPER 권한이 필요합니다.

이 변수에 대한 변경이 언제 활성화 영향은 얼마나 오래 지속 또는 관리하는 규칙은 다른 MySQL 서버 시스템 변수의 경우와 동일합니다. 자세한 내용은 섹션 13.7.4 "SET 구문" 을 참조하십시오.

MIXED 가 지정되어있는 경우 열 기반 리플리케이션 만 적절한 결과가 보장되는 경우를 제외하고 문 기반 복제가 사용됩니다. 예를 들어, 이것은 사용자 정의 함수 (UDF) 또는 UUID() 함수가 문에 포함되어있을 때 발생합니다. 이 규칙의 예외는 MIXED 이 스토어드 함수 및 트리거를 위해 항상 문 기반 복제를 사용하는 것입니다.

복제 형식을 실행할 때 전환 할 수없는 예외도 있습니다.

이러한 경우 형식을 전환하려고하면 오류가 발생합니다.

바이너리 로그 형식은 다음 서버 옵션의 동작에 영향을 미칩니다.

이러한 영향의 자세한 내용은 개별 옵션의 설명에 기재되어 있습니다.

binlog_gtid_recovery_simplified

MySQL 버전 5.6.21에서이 변수는 simplified_binlog_gtid_recovery 으로 추가되어 MySQL 버전 5.6.23에서 그 이름이 binlog_gtid_recovery_simplified 으로 바뀌 었습니다.

기본적으로 MySQL은 오류를 복구 할 때 바이너리 로그 파일을 반복하여 가장 오래된 파일부터 시작 GTID 이벤트를 검색하기 위해 대량의 바이너리 로그 파일이 있다면 이것은 시간이 걸릴 수 있습니다. 이 옵션을 사용하여 대신 가장 새로운 바이너리 로그 파일에서 GTID 이벤트가 검색됩니다. Previous_gtids_log_event 및 Gtid_log_event 가 감지되면 gtid_executed 과 gtid_purged 은 복구 중에 정상적으로 이러한 이벤트를 사용하여 초기화됩니다. GTID 이벤트가 감지되지 않으면 두 번째 스캔이 제일 낡은 바이너리 로그 파일에서 GTID 이벤트를 검색합니다. 이러한 파일의 어느쪽으로도 GTID 이벤트가 포함되지 않는 경우는 더 이상 바이너리 로그 파일은 검색되지 않고 gtid_executed 과 gtid_purged 은 빈 문자열로 설정됩니다.

binlogging_impossible_mode

이 옵션은 비추천으로 향후 MySQL 릴리스에서 제거 될 예정입니다. 이름이 변경된 binlog_error_action 을 사용하여 서버가 바이너리 로그에 기록 할 수없는 때 어떤 일이 일어나는지를 제어합니다.

binlog_max_flush_queue_time

그룹 커밋을 진행하기 전에 플래시 큐에서 트랜잭션 읽기 (및 sync_binlog 가 0보다 큰 경우는 로그와 디스크 동기화)를 얼마나 지속 할 것인지 (마이크로 초)입니다. 값이 0 (디폴트)의 경우 시간이 아니라 큐가 빌 때까지 서버는 새로운 트랜잭션의 읽기를 계속합니다.

일반적으로 binlog_max_flush_queue_time 을 0으로 설정되어 있어도 상관 없습니다. 서버가 대량의 연결 (예 : 100 이상) 및 낮은 지연 시간 요구 사항의 많은 짧은 트랜잭션을 처리하는 경우 0보다 큰 값을 설정하여 디스크에 플래시를 강제 더 빈번하게하는 것이 유용한 경우 수 있습니다.

이 변수는 MySQL 5.6.6에서 추가되었습니다.

binlog_order_commits

이 변수가 활성화되면 (기본값) 트랜잭션은 바이너리 로그에 기록되는 순서와 같은 순서로 커밋됩니다. 무효의 경우, 트랜잭션은 병렬로 커밋 될 수 있습니다. 경우에 따라이 변수를 해제하여 성능을 향상시킬 수 있습니다.

이 변수는 MySQL 5.6.6에서 추가되었습니다.

binlog_row_image

MySQL 열 기반 리플리케이션에서 각 행 변경 이벤트에 2 개의 이미지, 즉 " 전에 " 이미지 (갱신되는 행을 검색 할 때이 컬럼이 일치되는)과 " 후 " 이미지 (변경 포함)가 포함 합니다. 일반적으로 MySQL은 이전 및 이후 이미지 모두를 위해 모든 행 (즉, 모든 컬럼)를 기록합니다. 그러나 두 이미지에 모든 컬럼이 엄격에 포함되어있을 필요는없고, 많은 경우 실제로 필요한 컬럼의 로그만을 기록하여 디스크, 메모리 및 네트워크 사용량을 절약 할 수 있습니다.

이전 이미지에 대해서는 행을 고유하게 식별하는 데 필요한 최소 컬럼 세트가 기록되는 것만이 필요합니다. 행이있는 테이블에 기본 키가있는 경우, 프라이 머리 키 컬럼 만이 바이너리 로그에 기록됩니다. 그렇지 않고 테이블에 고유 키가 그 컬럼의 모든 것이 NOT NULL 의 경우는 고유 키의 컬럼의 로그만을 기록해야합니다. (테이블에 NULL 열없이 기본 키 또는 고유 키가없는 경우 모든 컬럼이 전에 이미지에서 사용되어 그 로그가 기록 될 필요가 있습니다.) 후 이미지는 실제로 변경된 컬럼 로그 만을 기록해야합니다.

MySQL 5.6에서는 서버에 binlog_row_image 시스템 변수를 사용하여 full 또는 minimal 행의 로그를 기록 할 수 있습니다. 이 변수는 실제로 다음 목록에서 세 가지의 가능한 값 중 하나를 취할 수 있습니다.

기본값은 full 입니다. MySQL 5.5 이전 이전 및 이후 이미지 모두에 항상 full 행 이미지가 사용됩니다. MySQL 5.6 이후의 마스터에서 이전 버전의 MySQL을 실행하기 때문에 슬레이브에 복제 할 필요가있는 경우 마스터는 항상이 값을 사용하십시오.

minimal 또는 noblob 를 사용할 때는 원본 테이블과 대상 테이블 모두에 대해 다음의 조건이 true의 경우에만 소정의 테이블에 삭제 및 업데이트가 제대로 작동하는 것이 보증됩니다.

(즉, 이러한 테이블은 동일해야하지만, 테이블의 기본 키의 일부가 아닌 인덱스가있는 경우에는 그 제외)

이러한 조건이 충족되지 않을 경우 대상 테이블의 프라이 머리 키 컬럼 값이 삭제 또는 갱신을위한 고유 일치를 제공하기 위해 충분하지 판명 될 수 있습니다. 이 경우 경고 또는 오류는 발생하지 않습니다. 마스터와 슬레이브는 자동으로 상이 일관성이 없습니다.

바이너리 로깅 형식이 STATEMENT 때이 변수를 설정해도 효과는 없습니다. binlog_format 이 MIXED 의 경우 binlog_row_image 설정 행 기반 형식을 사용하여 로그를 기록하는 변경에 적용되지만,이 설정은 문으로 로그가 기록되는 변경에 영향을주지 않습니다.

글로벌 또는 세션 레벨 중 하나 binlog_row_image 을 설정해도 암시 적으로 커밋되지 않습니다. 이것은 트랜잭션이 진행중인 트랜잭션에 영향을주지 않고이 변수를 변경할 수 있음을 의미합니다.

binlog_rows_query_log_events

binlog_rows_query_log_events 시스템 변수는 행 기반 로깅에만 영향을줍니다. 활성화하면, MySQL 5.6.2 이후 서버는 행 쿼리 로그 이벤트 등의 정보 로그 이벤트를 바이너리 로그에 기록합니다. 이 정보는 디버그 및 관련 목적 (마스터에서 발행 된 원본 쿼리를 행 업데이트에서 재구성 할 수 없을 때 그 쿼리를 취득하는 등)을 위해 사용할 수 있습니다.

이러한 이벤트는 일반적으로 바이너리 로그를 읽을 MySQL 5.6.2 이후의 프로그램에서 무시되므로 복제 또는 백업에서 복원 할 때 문제가 발생하지 않습니다. 이것은 MySQL 5.6.1 이전 mysqld 또는 mysqlbinlog 는 true가 없습니다. 로그를 읽을 이전 버전의 프로그램이 정보 로그 이벤트가 발생하면 그것은 실패하고 그 시점에서 읽기를 중지합니다. MySQL 5.6.1 이전 배포에서 슬레이브 복제 MySQL 서버 및 기타 리더 (예를 들어, mysqlbinlog )가 바이너리 로그를 읽을 수 있도록하려면 로깅 동안 binlog_rows_query_log_events 을 해제해야합니다.

binlog_stmt_cache_size

이 변수는 트랜잭션 중에 발행되는 비 트랜잭션 문을 유지하는 바이너리 로그 로그 캐시의 크기를 결정합니다. 서버가 트랜잭션 스토리지 엔진을 지원하며 서버에서 바이너리 로깅이 가능 ( --log-bin 옵션)가있는 경우 별도의 바이너리 로그 트랜잭션 및 명령문 캐시가 각 클라이언트에 할당됩니다. 트랜잭션 중에 큰 비 트랜잭션 문을 자주 사용하는 경우이 캐시 크기를 늘려 성능을 향상시킬 수 있습니다. Binlog_stmt_cache_use 및 Binlog_stmt_cache_disk_use 상태 변수는이 변수의 크기를 조정하는 경우에 유용 할 수 있습니다. 섹션 5.2.4 "바이너리 로그" 를 참조하십시오.

binlog_cache_size 시스템 변수는 트랜잭션 캐시의 크기를 설정합니다.

log_bin

바이너리 로그가 유효한지. --log-bin 옵션이 사용되는 경우,이 변수의 값은 ON 입니다. 그렇지 않으면 OFF 입니다. 이 변수는 바이너리 로깅 상태 (활성화 또는 비활성화)에 대해서만보고합니다. --log-bin 이 설정되어있는 값을 실제로보고하는 것은 아닙니다.

섹션 5.2.4 "바이너리 로그" 를 참조하십시오.

log_bin_basename

바이너리 로그 파일의 이름과 전체 경로를 유지합니다. log_bin 시스템 변수와는 달리 log_bin_basename 는 --log-bin 서버 옵션에서 설정되는 이름을 반영합니다.

log_bin_basename 시스템 변수는 MySQL 5.6.2에서 추가되었습니다.

log_bin_index

바이너리 로그 파일명의 인덱스 파일.

log_bin_index 시스템 변수는 MySQL 5.6.4에서 추가되었습니다.

log_bin_use_v1_row_events

MySQL 5.6.6 이후에 사용 가능한 버전 2 바이너리 로깅이 사용되었는지 여부를 나타냅니다. 값 1은 서버가 버전 1 로깅 이벤트 (MySQL 5.6.5 및 이전의 MySQL Server 릴리스에서 사용되는 바이너리 로그 이벤트의 유일한 버전)를 사용하여 바이너리 로그를 써 있고, 오래된 슬레이브에서 읽을 바이너리 로그 를 생성하는 것을 보여줍니다. 값 0은 버전 2 바이너리 로그 이벤트가 사용되는 것을 나타냅니다.

이 변수는 읽기 전용입니다. 버전 1 및 버전 2 바이너리 이벤트 바이너리 로깅을 전환하려면 mysqld 를 --log-bin-use-v1-row-events 옵션에서 다시 시작해야합니다.

MySQL Cluster 복제를 업그레이드 할 때를 제외하고는 --log-bin-use-v1-events 주로 NDB $ EPOCH_TRANS () (버전 2 진 행 이벤트 로깅이 필요)를 사용하여 복제 충돌 감지 및 해결을 설치하면 도움이됩니다. 따라서이 옵션과 --ndb-log-transaction-id 는 호환되지 않습니다.

자세한 내용은 섹션 18.6.11 "MySQL Cluster 복제 충돌 해결" 을 참조하십시오.

log_slave_updates

슬레이브 서버가 마스터 서버로부터받은 업데이트 로그를 슬레이브 자신의 바이너리 로그에 기록 할 필요가 있는지. 이 변수를 설정하려면 슬레이브에서 바이너리 로깅을 활성화해야합니다. 섹션 17.1.4 "복제 및 바이너리 로깅 옵션과 변수" 를 참조하십시오.

master_verify_checksum

이 변수를 사용하여 마스터 바이너리 로그에서 읽을 때 체크섬을 검사합니다. master_verify_checksum 은 기본적으로 비활성화되어 있습니다. 이 경우, 마스터 바이너리 로그에서 이벤트 장을 사용하여 이벤트를 검증하기 위해 다 모여 이벤트 만이 바이너리 로그에서 읽습니다.

이 변수는 MySQL 5.6.2에서 추가되었습니다.

max_binlog_cache_size

트랜잭션의 비 트랜잭션 문이 바이트 수보다 많은 메모리를 필요로하는 경우, 서버는 Multi-statement transaction required more than 'max_binlog_cache_size'bytes of storage 오류를 생성합니다. 최소값은 4096입니다. 가능한 최대 값은 16E 바이트 (엑사 바이트)입니다. 권장되는 최대 값은 4G 바이트입니다. 이것은 MySQL이 현재 4G 바이트보다 큰 바이너리 로그 위치에서 작업 할 수 없다는 사실에 더합니다.

max_binlog_cache_size 는 트랜잭션 캐시 만의 크기를 설정합니다. 문 캐시의 최대 값은 max_binlog_stmt_cache_size 시스템 변수에 의해 관리됩니다.

MySQL 5.6에서는 max_binlog_cache_size 세션의 가시성은 binlog_cache_size 시스템 변수와 일치합니다. 즉,이 값의 변경은 값이 변경된 후에 시작되는 새로운 세션에만 영향을줍니다.

max_binlog_size

바이너리 로그에 기록하여 현재 로그 파일 크기가이 변수 값을 초과하면 서버는 바이너리 로그를 순환합니다 (현재 파일을 닫고 새를 엽니 다). 최소값은 4096 바이트입니다. 최대 값과 디폴트 값은 1G 바이트입니다.

트랜잭션은 바이너리 로그에 한묶음으로 작성된 여러 바이너리 로그 사이에 분할 될 것은 없습니다. 따라서 큰 트랜잭션의 경우, max_binlog_size 보다 큰 바이너리 로그 파일을 볼 수 있습니다.

max_relay_log_size 가 0이면, max_binlog_size 의 값이 릴레이 로그에도 적용됩니다.

max_binlog_stmt_cache_size

트랜잭션의 비 트랜잭션 문이 바이트 수보다 많은 메모리를 필요로하는 경우, 서버는 오류를 생성합니다. 최소값은 4096입니다. 최대 값과 디폴트 값은 32 비트 플랫폼에서 4G 바이트 64 비트 플랫폼에서는 16E 바이트 (엑사 바이트)입니다.

max_binlog_stmt_cache_size 은 문 캐시 만의 크기를 설정합니다. 트랜잭션 캐시의 최대 값은 max_binlog_cache_size 시스템 변수에 의해 독점적으로 관리됩니다.

sync_binlog

이 변수의 값이 0보다 큰 경우는 sync_binlog 커밋 그룹이 바이너리 로그에 기록 된 후, MySQL 서버는 바이너리 로그를 디스크에 동기화합니다 ( fdatasync () 를 사용). sync_binlog 의 기본값은 0이며, 이것은 디스크에 동기화하지 않습니다. 이 경우 서버는 운영 체제에 의존하여 다른 파일에 대해 바이너리 로그의 내용을 가끔 플래시합니다. 값 1이 가장 안전한 선택입니다 (충돌의 경우에 바이너리 로그에서 손실 커밋 그룹이 최대 하나입니다). 그러나 가장 느린 선택이기도합니다 (디스크에 배터리 된 캐시가있는 경우를 제외합니다. 그 경우 동기화가 매우 빨라집니다).