본문 바로가기

MySQL/8.0 New Feature

MySQL 8.0 binlog_row_metadata

1. 개요

MySQL 8.0 에서 추가된 "binlog_row_metadata" 변수가 있다. 해당 값은 "MINIMAL" 과 "FULL" 값을 설정할 수 있다.
binlog 작성 시 row 의 meta 정보를 함께 기록하는 것인데, "FULL" 로 설정을 하게되면 MINIMAL 과 생각보다 큰 binlog 사이즈를 가지게 된다.

구성하는 요소가 무엇인지, 어떤 형식으로 binary log 에 남게되는지 보고자 한다. 해당 파라메터는 Global dynamic variable 이다.

 

 

2. binlog_row_metadata 란 ?

목적

1) 마스터와 슬레이브가 테이블 구조가 다를 경우, 슬레이브는 전송된 데이터로부터 metadata 를 사용
2) 외부 소프트웨어가 메타 데이터를 사용하여 row event 를 decode 하고 DW 와 같은 외부 데이터베이스에 데이터를 저장

 

 

설정 변수

1) MINIMAL (DEFAULT)
구성 : signed 플래그 + row string set + geometry 와 관련된 meta data

 

2) FULL
구성 : MINIMAL + Column name + ENUM or SET String Value + Primary Key 정보

 

 

3. setting value 별 로깅 방식 확인

"row_metadata=FULL" 경우, binary log 로깅 확인

1) binary log 를 포맷팅 할 때, 반드시 "--print-table-metadata" 옵션을 주어야 확인할 수 있음.

$ mysqlbinlog --print-table-metadata -vvv mysql-bin.000001 > uzi.sql

$ vi uzi.sql

...
...
...
BEGIN
/*!*/;
# at 1550
#190423 14:41:05 server id 41105176 end_log_pos 1612 CRC32 0xb328770c Table_map: `d1`. `t1` mapped to number 88

# Columns(`id` INT NOT NULL, `c1` INT, `c2` INT)
# Primary Key(id)
# at 1612
#190423 14:41:05 server id 41105176 end_log_pos 1656 CRC32 0x72aa1f4e Write_rows: table id 88 flags: STMT_END_F

BINLOG ' caW+XBMYN3MCPgAAAEwGAAAAAFgAAAAAAAEAAmQxAAJ0MQADAwMDAAYBAQAECQJpZAJjMQ JjMggB
AAx3KLM=
caW+XB4YN3MCLAAAAHgGAAAAAFgAAAAAAAEAAgADAwAEAAAAAwAAAE4fqnI=
'/*!*/;
### INSERT INTO `d1`.`t1`
### SET
### @1=4 /* INT meta=0 nullable=0 is_null=0 */
### @2=3 /* INT meta=0 nullable=1 is_null=0 */
# at 1656
#190423 14:41:05 server id 41105176 end_log_pos 1687 CRC32 0x6af0bb62 Xid = 41 COMMIT/*!*/;
...
...
...

위의 로깅된 내용처럼
컬럼의 정보 : " # Columns(`id` INT NOT NULL, `c1` INT, `c2` INT) " Primary Key 의 정보 : " # Primary Key(id) "
를 함께 남기는 것을 확인할 수 있다.

 

 

"row_metadata=FULL" 일시 슬레이브 선작업

"row_metadata=FULL" 일 경우 metadata 에 column name 의 정보가 포함되고, 또한 매뉴얼에는 마스터와 슬레이브의 구조가 다른 경우 row_metadata 를 사용한다 고 나와있다.

 

위 내용을 토대로 "binlog_format=ROW" 인 상황에서 슬레이브에서 먼저 테이블의 구조를 바꾼 뒤에 컬럼 값이 정상적으로 매핑되는지 확인해본다.

 

1) Master : create table t1 (id int auto_increment primary key, c1 int, c2 int);

 -- Slave 에 c3 컬럼을 중간 순서로 끼워넣는다.
2) Slave : alter table t1 add column c3 int after id;

3) Master : insert into t1 (c1, c2) values (1, 10);

4) Master & Slave : SELECT * FROM t1;

Master : SELECT * FROM t1;
+----+------+------+
| id | c1 | c2 |
+----+------+------+

| 1 | 1 | 10 |
+----+------+------+

Slave : SELECT * FROM t1;
+----+------+------+------+
| id | c3 | c1 | c2 |
+----+------+------+------+
| 1 | 1 | 10 | NULL |
+----+------+------+------+

해당 파라메터 설정과 별개로 기존 row format 에서 안고 있는 이슈가 동일하게 발생한다.

 

 

4. "row_metadata=FULL" 인 경우 어느 정도의 binary log 사이즈가 증가하는지 테스트

binlog_row_metadata = "MINIMAL"

MySQL 5.7 과 MySQL 8.0 의 큰 차이는 없다.

 

 

 

binlog_row_metadata = "FULL"

* MySQL 5.7 : 22개의 100M binary Log 생성

* MySQL 8.0 : 29개의 100M binary Log 생성

※ 동일 시간동안 동일한 트래픽을 주었다.


→ binlog_row_metadata=FULL 인 경우 5.7 에 비해 약 20% 이상 binary log 사이즈가 증가하는 것을 확인할 수 있다.

 

 

 

5. 결론

현재 상황에서 "binlog_row_metadata = FULL" 의 사용법은 아직은 뚜렷해보이지는 않는다.
그에 반해 binary log 사이즈는 확연하게 증가하고 있기 때문에, 사용처가 분명해지기 전까지는 아직은 굳이 적용할 필요가 없어보인다.

'MySQL > 8.0 New Feature' 카테고리의 다른 글

MySQL 8.0 binlog_row_value_options (JSON Type option)  (0) 2020.02.10
MySQL 8.0 Atomic DDL (data definition statement)  (0) 2020.02.03
MySQL 8.0 Optimizer Trace  (1) 2020.01.17
Descending Index  (0) 2019.02.18