행 레벨 replication은 종래의 replication하고 비교해서 다음과 같은 잇점이 있다.
- UDF나 FOUND_ROWS(), LOAD_FILE(), SYSDATE(), USER(), UUID()를 사용한 경우에도 replication이 가능
- 복잡한 SQL문을 slave가 순서대로 실행처리하는 것보다도 빠를 것이다라고 생각되어짐.
- 로그양이 증가한다.
- 처리가 큰 경우 Rollback된 데이터도 로그되는 경우가 있다.
- 인간이 바이너리로그를 보아도 판별되지 않는다.
- Slave가 어떤 SQL문을 받아 처리하는 지 알 수가 없다.
shell$ ./configure --without-row-based-replication
행 레벨 replication의 도입(binlog_format)
행 레벨 replication을 도입하려면 binlog_format변수에 바이너리로그 기술방법을 지정할 필요가 있다. mysqld의 옵션처리하려면 --binlog-format이다.
mysqld --binlog-format={ROW|1|STATEMENT|2|MIXED|3}
SET문으로도 변경가능하다.
mysql>SET GLOBAL binlog_format=2;
다음과 같은 경우는 SET문으로 동적으로 포맷을 변경할 수 없다.
- 스토어드 함수나 트리거 내부
- NDB가 유효한 경우
- 세션이 ROW베이스로 되어있고 임시 테이블을 사용하고 있을 경우
다음과 같은경우 replication할 수 없다.
- UDF를 사용했을 경우
- 다음과 같은 함수를 사용했을 경우 FOUND_ROWS(), LOAD_FILE(), USER(), UUID()
- SYSDATE() 를 --sysdate-is-now옵션이 없는 상태에서 사용한 경우
BINLOG '
3w0rRRMBAAAAJgAAACYAAAAAA4AAAAAAAAABHRlc3QAAWEAAQM=
';
값은 base64로 인코딩되어 있다. 이 값은 테이블 핸들러(스토리지엔진에 대한 핸들러)에 전달하는 값이다 ( handler::ha_write_row(), handler::ha_update_row(), handler::ha_delete_row()등)
3또는 MIXED는 MySQL 5.1.8에서 추가되었다. 보통은 STATEMENT와 마찬가지로 동작한다. 다음과 같은 경우는 ROW와 마찬가지로 바이너리로그를 기록한다.
- UDF나 UUID()를 사용한 경우
- NDB테이블에 대해서 INSERT, UPDATE, DELETE등의 데이터 조작
- INSERT DELAYED를 실행했을 경우
