Replication : 행 레벨 replication

MySQL 5.1.5-alpha에서 행 레벨 replication이 도입되었다.   구현 아이디어로는  바이너리 로그의 기술을 변경하자라는 것이다.

행 레벨 replication은 종래의 replication하고 비교해서  다음과 같은  잇점이 있다.

• UDF나 FOUND_ROWS(), LOAD_FILE(), SYSDATE(), USER(), UUID()를 사용한 경우에도 replication이 가능
• 복잡한 SQL문을 slave가  순서대로 실행처리하는 것보다도 빠를 것이다라고 생각되어짐. 

단점으로는 다음과 같은 것이 있다.

• 로그양이 증가한다. 
• 처리가 큰 경우 Rollback된 데이터도  로그되는 경우가 있다. 
• 인간이 바이너리로그를 보아도 판별되지 않는다. 
• Slave가 어떤 SQL문을 받아 처리하는 지 알 수가 없다. 

소스로 빌드하는 경우는 configure옵션에서 다음과 같이 지정하면 행 레벨 replication은 포함되지 않는다.

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베이스로 되어있고  임시 테이블을 사용하고 있을 경우 

1이나 STATEMENT는  종래와 마찬가지로  바이너리 로그에는 SQL문으로 변경사항을 기록한다.    행 레벨 replication으로 될 수 없다.
다음과 같은경우 replication할 수 없다.

• UDF를 사용했을 경우
• 다음과 같은 함수를 사용했을 경우 FOUND_ROWS(), LOAD_FILE(), USER(), UUID()
• SYSDATE() 를 --sysdate-is-now옵션이 없는 상태에서 사용한 경우 

2또는 ROW의 경우는 행레벨 replication이 가능하게 된다.  MySQL Cluster의 Replication을 수행할 경우에는  이 값으로 해야한다.  바이너리 로그에는 다음과 같이 기록된다.

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를 실행했을 경우