임시 테이블의 행 기반 로깅 섹션 17.4.1.22 "복제 및 임시 테이블" 에서 설명한 바와 같이 행 기반 형식을 사용하는 경우, 임시 테이블은 복제되지 않습니다. 혼합 형식 로깅을 사용하는 경우, 임시 테이블을 사용하는 "안전한"문은 명령문 기반 형식을 사용하여 로그가 기록됩니다. 자세한 내용은 섹션 17.1.2.1 "문 기반 및 열 기반 리플리케이션의 장점과 단점" 을 참조하십시오.

행 기반 형식을 사용하는 경우, 임시 테​​이블은 복제되지 않습니다 (필요가 없기 때문에). 또한 임시 테​​이블은 그들을 만든 스레드에서만 읽혀지기 때문에 문 기반 형식을 사용하는 경우에도 그들을 복제 할에서 얻을 수있는 혜택은 거의 없습니다.

MySQL 5.6에서는 임시 테​​이블이 작성된 경우에도 문베이스에서 행 기반 바이너리 로깅 모드를 전환 할 수 있습니다. 그러나 행 기반 형식의 사용은 MySQL 서버는 소정의 임시 테​​이블을 생성 할 때 효과적이었다 로깅 모드를 확인할 수 없습니다. 따라서 이러한 경우 서버는 소정의 클라이언트 세션이 종료 될 때, 거기에 여전히 존재하는 각 임시 테이블 DROP TEMPORARY TABLE IF EXISTS 문을 기록합니다. 이것은 어떤 경우 불필요한 DROP TEMPORARY TABLE 문이 기록 될 가능성이 있다는 것을 의미합니다,이 문은 무해하며 테이블이 존재하지 않는 경우에도 IF NOT EXISTS 옵션 있는 것으로 오류가 발생하지 않습니다.

MySQL 5.6.6 이전 버전에서는 열 기반 로깅을 사용할 때 --disable-gtid-unsafe-statements 옵션을 사용하면 임시 테이블을 사용하는 비 트랜잭션 DML 문이 오류로 실패했습니다 (바이너리 로그에 기록되지 않는다는 사실에 관계없이). MySQL 5.6.7 이후에는 문이 영향을 미치는 비 트랜잭션 테이블이 임시 테이블 인 한, binlog_format=ROW 를 사용하면 이러한 문이 허용됩니다 (Bug # 14272672).

비 트랜잭션 테이블의 RBL과 동기화 많은 행이 영향을받는 경우 변경 세트는 여러 이벤트로 분할됩니다. 문을 커밋하면이 이벤트의 모든 바이너리 로그에 기록됩니다. 슬레이브로 실행 중에 사용되는 모든 테이블에 테이블 잠금이 적용되어 행은 배치 모드에서 적용됩니다. (그것은 노예 의한 테이블 복사에 사용되는 엔진에 따라 효과적으로이거나 않을 수 있습니다.)

대기 시간 및 바이너리 로그 크기 RBL은 각 행의 변경을 바이너리 로그에 기록하므로 그 크기는 급격히 증가 할 수 있습니다. 따라서 마스터의 변경에 해당 변경 사항을 클라이언트에서 수행하는 데 필요한 시간이 크게 늘어날 수 있습니다. 응용 프로그램에서 이러한 지연이 발생할 가능성을 의식하십시오.

바이너리 로그 읽기 mysqlbinlog는 BINLOG 문을 사용하여 바이너리 로그의 행 기반 이벤트를 표시합니다 ( 섹션 13.7.6.1 "BINLOG 구문" 을 참조하십시오). 이 문은 base 64로 인코딩 된 문자열 (그 의미는 분명하지 않습니다)로 이벤트를 표시합니다. --base64-output=DECODE-ROWS 및 --verbose 옵션으로 호출 된 경우, mysqlbinlog 바이너리 로그의 내용을 사람이 읽을 수 있습니다. 바이너리 로그 이벤트가 행 기반 형식으로 기록되고 그들을 읽고 복제 또는 데이터베이스 장애 복구하고 싶다면이 명령에서 바이너리 로그의 내용을 읽을 수 있습니다. 자세한 내용은 섹션 4.6.8.2 "mysqlbinlog 행 이벤트보기" 를 참조하십시오.

바이너리 로그 실행 오류 및 slave_exec_mode slave_exec_mode 이 IDEMPOTENT 의 경우 원래의 행이 없기 때문에 RBL 변경 사항을 적용 할 수없는 경우에도 오류를 트리거하거나 복제가 실패하거나하지 않습니다. 이것은 업데이트가 슬레이브에 적용되지 않을 수 있기 때문에 마스터와 슬레이브가 동기화되지 않는 것을 의미합니다. slave_exec_mode 이 IDEMPOTENT 때의 RBR에서의 대기 시간 문제와 비 트랜잭션 테이블을 사용해서 마스터와 슬레이브 차이가 더 벌어 질 가능성이 있습니다. slave_exec_mode 에 대한 자세한 내용은 섹션 5.1.4 "서버 시스템 변수" 를 참조하십시오.

다른 시나리오의 경우 slave_exec_mode 을 STRICT 로 설정하여 일반적으로 충분하며 이것이 기본값입니다.

바이너리 로그 체크섬이없는 RBL은 체크섬을 사용하지 않기 때문에 바이너리 로그를 처리 할 때 네트워크, 디스크 및 기타 오류가 특정되지 않는 경우가 있습니다. 네트워크 손상없이 안정적으로 데이터를 전송하려면 복제 연결에 SSL을 사용합니다. CHANGE MASTER TO 문은 SSL을 사용하여 복제를 활성화하는 옵션이 있습니다. SSL을 사용하는 MySQL 설치에 대한 일반적인 정보는 섹션 13.4.2.1 "CHANGE MASTER TO 구문" 을 참조하십시오.

서버 ID를 기반 필터링은 지원되지 않는 MySQL 5.6에서는 CHANGE MASTER TO 문 IGNORE_SERVER_IDS 옵션을 사용하여 서버 ID를 기반으로 필터링 할 수 있습니다. 이 옵션은 명령문 기반 및 행 기반 로깅 형식으로 사용할 수 있습니다. 일부 슬레이브로 변경을 제외하기위한 다른 방법은 UPDATE 및 DELETE 문에서 관계 @@server_id <> id_value 절이 포함 된 WHERE 절을 사용하는 것입니다. 예를 들어 WHERE @@server_id <> 1 . 그러나 이것은 행 기반 로깅이 제대로 작동하지 않습니다. 문 필터링에 server_id 시스템 변수를 사용하려면 명령문 기반 로깅을 사용합니다.

데이터베이스 수준 복제 옵션 --replicate-do-db , --replicate-ignore-db 및 --replicate-rewrite-db 옵션의 효과는 행 기반 또는 명령문 기반의 두 로깅이 사용되는지에 따라 상당히 다릅니다. 따라서 데이터베이스 수준 옵션은 피하고 대신에 --replicate-do-table 과 --replicate-ignore-table 등의 테이블 수준 옵션을 사용하는 것이 좋습니다. 이러한 옵션과 복제 형식이 그 동작에 어떤 영향을 주는지에 대한 자세한 내용은 섹션 17.1.4 "복제 및 바이너리 로깅 옵션과 변수" 를 참조하십시오.

RBL 비 트랜잭션 테이블 및 중지 슬레이브 행 기반 로깅을 사용할 때 슬레이브 서버가 정지하고 슬레이브 쓰레드가 비 트랜잭션 테이블을 업데이트하는 경우, 슬레이브 데이터베이스가 불일치 상태에 도달 할 가능성 수 있습니다. 따라서 행 기반 형식을 사용하여 복제 된 모든 테이블에 InnoDB 등의 트랜잭션 스토리지 엔진을 사용하는 것이 좋습니다. 슬레이브 MySQL 서버를 종료하기 전에 STOP SLAVE 또는 STOP SLAVE SQL_THREAD 을 사용하는 것은 문제 발생의 방지에 도움이 사용하는 로깅 형식이나 스토리지 엔진에 관계없이 항상 권장됩니다.