pg_recvlogical 분석

Replication Data 증가량

원본 데이터에서 Replication 되어 저장되는 데이터는 아래와 같다.

BEGIN 1800
table public.pg_class_bak: INSERT: relname[name]:'user_mappings' relnamespace[oid]:12949 reloptions[text[]]:null
COMMIT 1800

BEGIN 과 COMMIT으로 TRANSACTION의 시작과 종료를 명시하며 TRANSACTION_ID를 통하여 어떤 트랜잭션인지 알린다. 그 사이에 트랜잭션에서 수행된 데이터가 쌓이게 되며, [테이블명, DML타입, 컬럼명[데이터타입]:값...(컬럼명 반복)]의 포맷을 따른다. ROW단위로 쌓이기 때문에 원본 데이터에 비하여 추가되는 메타 데이터 양이 많아 원본 대비 3~4배 이상의 데이터 증가량을 보인다.

pg_recvlogical 데이터 흐름도

DML 발생 -> WAL로그(pg_xlog) -> replication로그(pg_replslot) -> pg_recvlogical

우선 pg_recvlogical은 DML만 전송 가능하다. SELECT, DDL 등은 처리 불가다. 그렇기 때문에 DDL 변경 시에는 TRIGGER를 통한 방법이 가능한지 확인이 필요하다.

TRANSACTION의 시작과 함께 WAL로그에 데이터가 기록되게 된다. 이 기록된 데이터는 내부적 정책에 따라 추가적인 상태정보와 함께 Replication로그로 이관되게 된다.

데이터는 TRANSACTION이 종료될 때까지 Replication로그에 쌓이며 pg_recvlogical 로 전송되지 않는다. 즉 COMMIT된 데이터만 pg_recvlogical로 전송된다.

그런 이유로 대==량 데이터를 하나의 트랜잭션에서 처리 시에 Replication로그에 트랜잭션 종료까지 모든 데이터가 쌓이게 되며,== 이는 pg_recvlogical로 전송이 완료될 때까지

지속된다.

==replication로그는 pg_recvlogical이 기동되었을 때만 데이터가 쌓이며, 기동되어 있지 않았을 시에는 TRANSACTION 로그에 데이터를 유지==하여 pg_recvlogical이 기동되

었을 때, replication로그를 다시 저장하고 미전송된 데이터를 보낼 수 있도록 한다. 즉, DB 혹은 pg_recvlogical의 Crash에 대한 복구가 가능하다. 다만, pg_recvlogical이

정상화될 때까지 TRANSACTION로그가 정리되지 않고 계속 쌓이기 때문에 디스크 가용량 문제가 발생할 수 있다.

pg_recvlogical 특정 테이블 설정

wal2json 플러그인을 사용하여 slot을 생성하고, limit-to 옵션으로 특정 테이블만 replication을 받는다.

pg_recvlogical -d postgres --slot regression_slot --create-slot -P wal2json
pg_recvlogical -d postgres --slot regression_slot --start -o limit-to=table_foo,table_bar

pg_recvlogical 분석 - kayform/bwcontrol GitHub Wiki