--- title: "binlog_format 선택: ROW, STATEMENT, MIXED의 차이와 안전성" description: "MySQL 바이너리 로그 형식별 기록 방식과 복제 안전성, 용량·CDC 영향, 운영 선택 기준을 체계적으로 정리한다." tags: [ MySQL, 복제, 운영, DBA ] image: "mysql-report-bg.png" published: "2026-09-01" updated: "2026-09-01" author: "MySQL 기술 노트" source_url: "" --- # binlog_format 선택: ROW, STATEMENT, MIXED의 차이와 안전성 `binlog_format`은 단순한 로그 출력 형식이 아니다. 원본 서버에서 발생한 변경을 replica와 CDC(Change Data Capture) 소비자에게 어떤 의미 단위로 전달할지를 정하는 복제 계약이다. 같은 `UPDATE`라도 `STATEMENT`는 실행한 SQL을 기록하고, `ROW`는 변경된 행 이미지를 기록하며, `MIXED`는 문장의 안전성 판정에 따라 두 방식을 선택한다. 형식을 잘못 선택하면 replica 데이터가 원본과 달라지거나, CDC가 필요한 열 정보를 얻지 못하거나, 대량 갱신이 예상보다 큰 binary log를 만들어 보존 공간과 네트워크를 압박할 수 있다. 반대로 로그 크기만 줄이려고 `STATEMENT`를 선택하면 애플리케이션 SQL의 비결정성이 복제 정확성 문제로 바뀔 수 있다. 따라서 선택 기준은 “어느 형식이 더 빠른가”가 아니라 **정확성, 소비자 호환성, 변경량, 장애 복구 요구를 함께 만족하는가**여야 한다. ## 1. Binary log가 담당하는 범위 MySQL binary log는 커밋된 데이터 변경과 일부 관리 이벤트를 순서대로 기록한다. 대표적인 사용처는 다음과 같다. - source-replica 복제 - point-in-time recovery(PITR) - Debezium, AWS DMS 같은 CDC - 변경 감사와 장애 원인 분석을 위한 보조 자료 - 외부 MySQL 또는 Aurora MySQL로의 논리 복제 InnoDB redo log와 binary log는 목적이 다르다. redo log는 InnoDB 페이지 변경을 복구하기 위한 물리적 내부 로그이고, binary log는 서버 계층에서 논리적 변경 이력을 제공한다. 커밋 과정에서는 두 로그의 일관성이 중요하지만, `binlog_format`은 redo 기록 방식을 바꾸지 않는다. ```mermaid flowchart LR A[클라이언트 SQL] --> B[MySQL 서버 계층] B --> C[InnoDB 변경] C --> D[Redo log와 데이터 페이지] B --> E{binlog_format} E -->|STATEMENT| F[Query event 중심] E -->|ROW| G[Table map과 Row event] E -->|MIXED| H[문장별 안전성 판정] F --> I[Replica 또는 CDC] G --> I H --> I ``` DDL은 `ROW`를 선택해도 행 이미지로 표현되지 않고 SQL 이벤트로 기록될 수 있다. `ROW`라는 이름을 모든 이벤트가 row event가 된다는 뜻으로 해석하면 안 된다. 핵심 차이는 테이블의 DML 변경을 어떻게 표현하는가에 있다. ## 2. 세 형식의 내부 동작 ### 2.1 STATEMENT: 실행한 SQL을 전달한다 `STATEMENT`는 원본에서 실행된 변경 SQL을 binary log에 기록하고 replica가 같은 문장을 다시 실행한다. 한 문장으로 수백만 행을 바꾸더라도 로그에는 문장 하나와 실행에 필요한 부가 정보가 기록되므로, 행별 이벤트보다 작을 가능성이 크다. 그러나 결과가 실행 환경에 의존하면 문제가 된다. replica는 source와 데이터, 실행 순서, 세션 상태, 함수 평가 결과가 동일해야 같은 행을 만들 수 있다. 다음 패턴은 특히 주의해야 한다. - `ORDER BY` 없이 `LIMIT`을 사용한 변경 - `UUID()`처럼 실행할 때마다 결과가 달라지는 함수 - `AUTO_INCREMENT` 할당 순서가 행 처리 순서에 의존하는 `INSERT ... SELECT` - source와 replica의 데이터 상태 또는 시스템 상태가 다르면 결과가 달라지는 문장 - stored function, trigger, event 안에서 비결정적 동작을 수행하는 경우 - 서로 다른 storage engine이나 collation 동작에 영향을 받는 경우 MySQL은 일부 문장을 unsafe로 판정해 경고할 수 있지만, 이 판정이 애플리케이션의 모든 의미적 비결정성을 증명해 주는 것은 아니다. “경고가 없었다”와 “업무 결과가 결정적이다”는 같은 명제가 아니다. ### 2.2 ROW: 실제 변경 결과를 전달한다 `ROW`는 SQL 문자열을 replica에서 다시 평가하는 대신, 원본에서 변경된 행의 before image와 after image를 row event로 기록한다. 따라서 replica는 source가 이미 결정한 결과를 적용한다. 비결정적 함수나 실행 계획 차이가 replica 결과를 다시 바꾸지 않는다는 점이 가장 큰 장점이다. 일반적인 흐름은 다음과 같다. 1. `TABLE_MAP_EVENT`가 대상 테이블을 식별한다. 2. `WRITE_ROWS_EVENT`, `UPDATE_ROWS_EVENT`, `DELETE_ROWS_EVENT`가 행 변경을 표현한다. 3. replica applier 또는 CDC 도구가 row event를 해석한다. 4. 트랜잭션 경계에서 변경이 원자적으로 적용된다. 안전성이 높지만 비용이 사라지는 것은 아니다. 한 문장으로 많은 행을 갱신하면 각 행의 변경 이벤트가 생성되므로 binary log가 커질 수 있다. 큰 트랜잭션은 source의 로그 생성, replica 전송, relay log, applier 지연, CDC 버퍼와 downstream 처리량을 동시에 압박한다. ### 2.3 MIXED: 문장 단위로 자동 전환한다 `MIXED`는 기본적으로 statement 방식으로 기록하다가 MySQL이 statement 방식에 안전하지 않다고 판단한 문장을 row 방식으로 전환한다. 로그 크기와 안전성의 절충안처럼 보이지만, 실제 운영에서는 다음 두 가지를 구분해야 한다. - **서버가 판정할 수 있는 unsafe 조건**: MySQL 규칙에 따라 row 방식으로 전환된다. - **업무 의미상 위험하지만 서버가 판정하기 어려운 조건**: statement로 남을 수 있으므로 설계와 테스트가 필요하다. 따라서 `MIXED`는 “모든 위험을 자동으로 해결하는 ROW”가 아니다. 문장별 실제 event 형식이 달라질 수 있어 CDC 도구의 요구 조건도 확인해야 한다. row event를 전제로 하는 CDC라면 처음부터 `ROW`를 명시하는 편이 운영 계약을 단순하게 만든다. ## 3. 비교 기준 | 기준 | STATEMENT | ROW | MIXED | |---|---|---|---| | 기록 단위 | 실행 SQL | 변경된 행 이미지 | 문장별 SQL 또는 행 이미지 | | 복제 결정성 | SQL 특성에 크게 의존 | 원본 결과를 전달하므로 높음 | 자동 판정 범위에서는 개선 | | 대량 단일문 로그 크기 | 작을 수 있음 | 변경 행 수에 비례해 커질 수 있음 | 선택된 형식에 따라 달라짐 | | CDC 호환성 | 제한적일 수 있음 | 일반적으로 가장 명확함 | 소비자가 두 형식을 모두 처리해야 함 | | 문제 분석 | 원문 SQL 확인이 쉬움 | 어떤 행이 바뀌었는지 확인이 쉬움 | 이벤트마다 해석 방식이 달라짐 | | 비결정적 함수 | 위험 | 원본 평가 결과를 전달 | unsafe 판정 시 ROW 전환 | | 기본 권고 방향 | 특별한 이유가 있을 때만 | 범용 안전 기본값 | 기존 호환성·용량 절충 시 검토 | 이 표는 절대적인 성능 순위를 뜻하지 않는다. 최종 비용은 변경 행 수, 열 폭, `binlog_row_image`, 압축과 네트워크, replica 병렬 적용, CDC 처리 방식에 따라 달라진다. ## 4. 현재 설정과 관련 변수를 확인하는 SQL 운영 변경 전에 global 값과 현재 세션 값을 함께 확인해야 한다. 이미 연결된 세션은 새 global 값과 다른 session 값을 유지할 수 있기 때문이다. ```sql SELECT VERSION() AS mysql_version, @@GLOBAL.binlog_format AS global_format, @@SESSION.binlog_format AS session_format, @@GLOBAL.binlog_row_image AS row_image, @@GLOBAL.binlog_row_metadata AS row_metadata, @@GLOBAL.log_bin AS binary_logging_enabled; ``` 실행 결과(MySQL 8.0.x): ```text mysql> SELECT VERSION() AS mysql_version, -> @@GLOBAL.binlog_format AS global_format, -> @@SESSION.binlog_format AS session_format, -> @@GLOBAL.binlog_row_image AS row_image, -> @@GLOBAL.binlog_row_metadata AS row_metadata, -> @@GLOBAL.log_bin AS binary_logging_enabled; +---------------+---------------+----------------+-----------+--------------+------------------------+ | mysql_version | global_format | session_format | row_image | row_metadata | binary_logging_enabled | +---------------+---------------+----------------+-----------+--------------+------------------------+ | 8.0.46 | ROW | ROW | FULL | MINIMAL | 0 | +---------------+---------------+----------------+-----------+--------------+------------------------+ 1 row in set (0.00 sec) ``` `binary_logging_enabled`가 `OFF`라면 format 값이 존재하더라도 실제 binary log 이벤트는 생성되지 않는다. 검증 환경의 설정과 운영 서버의 설정을 혼동하지 않아야 한다. 변수 목록은 `performance_schema`에서 일정한 형태로 조회할 수 있다. ```sql SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ( 'binlog_format', 'binlog_row_image', 'binlog_row_metadata', 'log_bin', 'sync_binlog' ) ORDER BY VARIABLE_NAME; ``` 실행 결과(MySQL 8.0.x): ```text mysql> SELECT VARIABLE_NAME, VARIABLE_VALUE -> FROM performance_schema.global_variables -> WHERE VARIABLE_NAME IN ( -> 'binlog_format', -> 'binlog_row_image', -> 'binlog_row_metadata', -> 'log_bin', -> 'sync_binlog' -> ) -> ORDER BY VARIABLE_NAME; +---------------------+----------------+ | VARIABLE_NAME | VARIABLE_VALUE | +---------------------+----------------+ | binlog_format | ROW | | binlog_row_image | FULL | | binlog_row_metadata | MINIMAL | | log_bin | OFF | | sync_binlog | 1 | +---------------------+----------------+ 5 rows in set (0.00 sec) ``` `sync_binlog`은 형식 선택과 별개로 binary log flush 내구성에 영향을 준다. `ROW`를 선택했다고 해서 커밋 내구성까지 자동으로 강화되는 것은 아니다. binary log cache가 메모리를 넘어서 임시 파일을 사용했는지도 확인할 수 있다. ```sql SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME IN ( 'Binlog_cache_use', 'Binlog_cache_disk_use', 'Binlog_stmt_cache_use', 'Binlog_stmt_cache_disk_use' ) ORDER BY VARIABLE_NAME; ``` 실행 결과(MySQL 8.0.x): ```text mysql> SELECT VARIABLE_NAME, VARIABLE_VALUE -> FROM performance_schema.global_status -> WHERE VARIABLE_NAME IN ( -> 'Binlog_cache_use', -> 'Binlog_cache_disk_use', -> 'Binlog_stmt_cache_use', -> 'Binlog_stmt_cache_disk_use' -> ) -> ORDER BY VARIABLE_NAME; +----------------------------+----------------+ | VARIABLE_NAME | VARIABLE_VALUE | +----------------------------+----------------+ | Binlog_cache_disk_use | 0 | | Binlog_cache_use | 0 | | Binlog_stmt_cache_disk_use | 0 | | Binlog_stmt_cache_use | 0 | +----------------------------+----------------+ 4 rows in set (0.00 sec) ``` `Binlog_cache_disk_use`가 지속적으로 증가한다고 즉시 장애로 판단해서는 안 된다. 관측 구간의 트랜잭션 수와 큰 트랜잭션 발생 시점, `binlog_cache_size`, 임시 디스크 지연을 함께 봐야 한다. 비율과 증가 속도가 중요하다. ## 5. ROW 형식에서 함께 결정할 변수 ### 5.1 binlog_row_image `binlog_row_image`는 row event에 어느 열을 포함할지 조정한다. - `FULL`: before/after image에 필요한 전체 행 정보를 폭넓게 기록한다. 로그는 커질 수 있지만 CDC와 복구 도구의 호환성이 가장 단순하다. - `MINIMAL`: 행 식별과 실제 변경 적용에 필요한 열 중심으로 기록한다. 로그 크기를 줄일 수 있지만 downstream이 변경되지 않은 열까지 기대하면 문제가 된다. - `NOBLOB`: 변경되지 않은 `BLOB`·`TEXT` 계열 값을 줄이는 절충안이다. `MINIMAL`은 무조건적인 최적화가 아니다. CDC가 after image를 완전한 레코드로 간주하거나, schema evolution 과정에서 키 식별이 불안정하거나, 감사 시스템이 변경 전 전체 값을 요구하면 기능 손실이 발생할 수 있다. 변경 전에는 소비자별 지원 범위를 먼저 확인해야 한다. ### 5.2 binlog_row_metadata `binlog_row_metadata`는 row event와 함께 전달되는 테이블 메타데이터의 양을 조절한다. 메타데이터를 풍부하게 하면 CDC 해석과 schema 변화 대응에 도움이 될 수 있지만 event 크기도 늘어난다. 이 변수만으로 모든 schema 정보를 보장한다고 가정하지 말고, 사용 중인 connector가 MySQL metadata와 schema registry를 어떻게 조합하는지 확인해야 한다. ### 5.3 Primary Key와 행 식별 `ROW` 기반 복제에서 primary key가 없는 테이블은 replica 적용과 CDC 처리에 불리하다. 특히 `UPDATE`와 `DELETE`의 대상 행을 찾을 때 효율적인 유일 키가 없으면 replica가 많은 행을 탐색할 수 있다. 형식을 `ROW`로 바꾸는 작업은 다음 점검과 함께 진행하는 편이 안전하다. - 변경 빈도가 높은 테이블에 안정적인 primary key가 있는가 - nullable unique key만으로 행 식별을 기대하고 있지 않은가 - CDC connector가 keyless table을 어떻게 표현하는가 - replica에서 적용 지연이 특정 테이블에 집중되는가 ## 6. 실제 event를 확인하는 절차 형식을 선택한 뒤 변수 값만 확인해서는 부족하다. staging 환경에서 대표 트랜잭션을 실행하고 실제 binary log event를 확인해야 한다. 다음 명령은 실행 환경에 맞게 파일명과 위치를 조정하는 운영 절차 예시다. ```text mysqlbinlog --base64-output=DECODE-ROWS --verbose mysql-bin.000123 mysqlbinlog --start-datetime="2026-09-01 08:00:00" \ --stop-datetime="2026-09-01 08:10:00" \ --base64-output=DECODE-ROWS --verbose mysql-bin.000123 ``` 확인할 항목은 다음과 같다. 1. `STATEMENT` 또는 `MIXED`에서 의도한 문장이 실제로 Query event인지 row event인지 확인한다. 2. `ROW`에서 `UPDATE_ROWS_EVENT`의 before/after image가 CDC 요구를 충족하는지 확인한다. 3. 한 트랜잭션의 event 크기와 replica 적용 시간을 측정한다. 4. DDL과 DML의 순서가 소비자에서 올바르게 처리되는지 확인한다. 5. 민감한 열이 row event에 포함되어 로그 접근 통제가 필요한지 확인한다. Binary log는 평문 SQL뿐 아니라 변경된 데이터 값을 포함할 수 있다. `ROW` 전환은 로그 접근 권한, 보존, 백업 암호화, 외부 전송 구간의 통제까지 함께 검토해야 한다. ## 7. 변경 절차와 운영상의 함정 ### 7.1 global 변경과 기존 세션 `binlog_format`은 서버 버전과 배포 형태에 따라 동적 변경 가능 범위와 권한 요구가 달라질 수 있다. 또한 트랜잭션 중이거나 replication thread가 동작하는 상황에서는 변경이 제한될 수 있다. 운영에서는 즉석 `SET GLOBAL`만으로 끝내지 말고 다음 순서를 따른다. 1. 대상 버전의 지원 범위와 deprecation 상태를 확인한다. 2. 구성 파일 또는 parameter group을 source of truth로 변경한다. 3. 신규 연결의 session 값이 기대와 같은지 확인한다. 4. connection pool의 기존 세션을 계획적으로 교체한다. 5. replica와 CDC consumer가 새 event를 처리하는지 검증한다. 6. 재시작 또는 failover 뒤에도 값이 유지되는지 확인한다. 구성 예시는 다음과 같다. 실제 적용 위치와 재시작 필요 여부는 배포 환경에서 확인한다. ```text [mysqld] binlog_format=ROW binlog_row_image=FULL ``` 새로운 MySQL 버전에서는 `STATEMENT`와 `MIXED`의 장기 지원 방향이 달라질 수 있으므로, 신규 시스템은 `ROW`를 기준으로 설계하고 업그레이드 전에 release note와 변수 상태를 다시 확인하는 편이 안전하다. ### 7.2 형식 변경 중 열린 트랜잭션 한 트랜잭션의 중간에서 형식을 바꾸려고 해서는 안 된다. 형식 전환은 트래픽이 안정적이고 장기 트랜잭션이 통제된 변경 창에서 수행한다. 특히 connection pool이 session 변수를 개별 설정한다면 global 값과 다른 세션이 장시간 공존할 수 있다. ### 7.3 로그 용량만 보고 되돌리는 오류 `ROW` 전환 뒤 binary log가 커졌다면 먼저 다음 원인을 분리한다. - 대량 갱신 또는 삭제 트랜잭션 - 불필요하게 넓은 행과 `FULL` image - 짧은 보존 기간으로도 감당할 수 없는 change rate - CDC 지연으로 인한 로그 보존 연장 - replica 장애로 purge가 지연되는 구조 바로 `STATEMENT`로 되돌리기보다 트랜잭션 배치 크기, table 설계, image 정책, 보존 용량과 소비자 처리량을 조정해야 한다. 정확성을 희생해 저장 공간 문제를 가리는 것은 적절한 해결이 아니다. ## 8. Aurora MySQL에서의 해석 Aurora의 storage replication과 MySQL binary log replication은 별개다. Aurora cluster 내부의 고가용성은 분산 storage 계층이 담당하며, binary log는 주로 외부 MySQL 복제, CDC, 마이그레이션과 같은 논리 변경 스트림이 필요할 때 사용한다. 운영 시에는 다음 차이를 반영한다. - `binlog_format`은 DB cluster parameter group에서 관리한다. - parameter의 apply type과 `pending-reboot` 여부를 확인하고 writer와 reader의 적용 상태를 검증한다. - 외부 CDC가 row event를 요구하면 일반적으로 `ROW`와 적절한 `binlog_row_image`를 명시한다. - binary logging을 활성화하면 writer의 로그 생성과 보존 비용이 늘 수 있으므로 실제 change rate로 측정한다. - Aurora의 backup/PITR가 존재하더라도 외부 logical replication의 event 호환성 검증은 별도로 필요하다. - Aurora enhanced binlog 사용 가능 여부와 지원 엔진 버전을 확인하되, 이를 format 안전성 검증의 대체물로 보지 않는다. AWS 문서가 특정 연결 시나리오에 `MIXED`를 권고할 수 있지만, DMS나 다른 CDC가 `ROW`를 요구하는 경우가 있다. 서비스 일반 권고보다 실제 소비자 계약을 우선해야 한다. ## 9. 대표적인 실패 모드 ### 실패 모드 1: STATEMENT에서 source와 replica 결과가 달라짐 비결정적 SQL 또는 행 처리 순서 의존 SQL이 원인일 수 있다. 경고 로그, `mysqlbinlog`의 Query event, 테이블 checksum과 업무 키를 함께 확인한다. 데이터가 이미 달라졌다면 형식 변경만으로 과거 불일치가 복구되지는 않는다. 재동기화 계획이 필요하다. ### 실패 모드 2: ROW 전환 후 로그와 네트워크가 급증함 대량 DML의 변경 행 수와 평균 row event 크기를 측정한다. 큰 트랜잭션을 작은 단위로 나누고, replica/CDC가 소비할 수 있는 처리량을 확보한다. `MINIMAL`은 downstream 호환성이 확인된 경우에만 적용한다. ### 실패 모드 3: CDC 레코드에 필요한 열이 없음 `binlog_row_image=MINIMAL`, primary key 부재, connector 설정 또는 schema history 손실을 확인한다. source 변수만 바꾸기 전에 consumer 재처리와 schema 복구 절차를 준비한다. ### 실패 모드 4: global 값은 ROW인데 일부 event가 예상과 다름 기존 session 값, session-level override, DDL event 특성, connection pool 초기화 SQL을 확인한다. global 변수 한 번의 조회만으로 모든 연결의 실제 동작을 단정해서는 안 된다. ### 실패 모드 5: replica 적용 지연이 증가함 행별 이벤트 수가 증가하면서 applier가 병목이 될 수 있다. primary key 부재, 큰 단일 트랜잭션, replica I/O, parallel replication 설정, 종속성 단위를 함께 분석한다. source의 binary log 생성 속도만 보는 것은 불충분하다. ## 10. 선택 기준 다음 조건이면 `ROW`를 기본값으로 두는 것이 합리적이다. - 데이터 정확성이 로그 크기보다 우선한다. - CDC 또는 외부 데이터 파이프라인이 row event를 요구한다. - 비결정적 SQL을 완전히 통제하기 어렵다. - MySQL 8.0 이상 신규 시스템을 설계한다. - 원본의 실행 결과를 replica에서 그대로 재현하는 계약이 중요하다. `MIXED`는 다음 조건을 모두 검토한 뒤 선택한다. - 기존 시스템이 statement event와 row event를 모두 안정적으로 처리한다. - 대량 변경의 로그 크기를 줄일 실질적 이유가 있다. - unsafe 자동 전환 규칙의 한계를 이해하고 대표 SQL을 검증했다. - CDC가 혼합 event를 허용한다. `STATEMENT`는 호환성 또는 특수한 운영 제약이 분명하고, SQL 결정성을 조직적으로 통제할 수 있을 때 제한적으로 고려한다. 단순히 로그가 작을 것이라는 기대만으로 선택해서는 안 된다. ## 11. 변경 전후 체크리스트 ### 변경 전 - [ ] source, replica, CDC 소비자의 지원 형식을 확인했다. - [ ] 대표 DML에서 비결정 함수와 순서 의존성을 점검했다. - [ ] 모든 고변경 테이블의 primary key 유무를 확인했다. - [ ] 현재 binary log 생성량과 보존 여유 공간을 측정했다. - [ ] `binlog_row_image`와 `binlog_row_metadata` 요구를 정리했다. - [ ] 장기 트랜잭션과 connection pool session 교체 계획이 있다. - [ ] staging에서 실제 event를 `mysqlbinlog --verbose`로 확인했다. ### 변경 후 - [ ] global 값과 신규 session 값이 모두 기대한 형식이다. - [ ] 대표 Query event와 Row event를 직접 확인했다. - [ ] replica lag와 applier 처리량이 허용 범위다. - [ ] CDC schema와 key가 정상적으로 해석된다. - [ ] `Binlog_cache_disk_use` 증가 추세와 임시 디스크 지연을 점검했다. - [ ] binary log 일일 생성량과 보존 용량을 다시 산정했다. - [ ] failover 또는 재시작 뒤에도 parameter가 유지된다. - [ ] rollback 기준과 데이터 재동기화 절차를 문서화했다. ## 12. 결론 `binlog_format`의 핵심 선택 기준은 로그 크기가 아니라 변경 의미를 얼마나 결정적으로 전달할 수 있는가이다. `STATEMENT`는 간결할 수 있지만 실행 환경에 대한 가정이 많고, `ROW`는 원본 결과를 전달해 복제와 CDC 계약을 단순하게 만들지만 변경량에 비례한 비용이 발생한다. `MIXED`는 일부 위험을 자동으로 줄이지만 서버의 판정 범위를 넘어서는 업무 의미까지 보증하지는 않는다. 대부분의 신규 MySQL 8.0 이상 환경에서는 `ROW`를 안전한 출발점으로 두고, `binlog_row_image`, primary key, 트랜잭션 크기, CDC 호환성, 보존 용량을 함께 설계하는 편이 타당하다. 다음 단계에서는 binary log row image와 metadata가 CDC 페이로드, replica 적용, 장애 복구 가능성에 어떤 영향을 주는지 더 세밀하게 다룰 수 있다.