Summary#
PostgreSQL의 내장 논리 복제는 테이블 데이터 변경을 전달하지만 스키마 정의와 DDL은 복제하지 않는다. 따라서 발행자에서 열을 추가·삭제하거나 타입을 바꾼 뒤 구독자 스키마를 호환되게 유지하지 않으면, 새 데이터 변경의 적용이 오류를 내며 멈출 수 있다. 기본 복구 방향은 실패한 트랜잭션을 건너뛰는 것이 아니라 구독자 스키마를 바로잡고 적용이 다시 진행되는지 확인하는 것이다. (postgresql.org)
Key Points#
- 불일치가 생기는 경로: 발행자의 DDL은 구독자에 자동 실행되지 않는다. 테이블은 스키마를 포함한 이름으로, 열은 이름으로 대응한다. 구독자에 열이 더 있어도 기본값으로 채울 수 있지만, 발행자가 보내는 변경을 구독자 테이블에 적용할 수 없는 상태라면 복제 오류가 난다. 열 순서가 다르다는 사실만으로는 불일치가 아니다. (postgresql.org)
- 변경 순서: 호환 가능한 열 추가처럼 확장적(additive) 변경은 구독자에 먼저 적용한 뒤 발행자에 적용하면 일시적인 오류를 피할 수 있는 경우가 많다. 열 삭제·이름 변경·타입 변경은 같은 순서를 기계적으로 적용하지 말고, 변경 전후 양쪽에서 전달될 데이터가 적용 가능한지 검토해야 한다. (postgresql.org)
- 진단: 구독자의 서버 로그에서 실패한 테이블과 실제 오류를 확인한다.
pg_stat_subscription에서 적용 작업자의 상태와 수신 위치를,pg_stat_subscription_stats에서apply_error_count의 증가를 살핀다. 통계 수치만으로 오류 원인이 스키마라고 단정할 수는 없다. (postgresql.org) - 복구: 로그의 오류와 양쪽 테이블 정의를 대조해 구독자를 호환 상태로 수정한 다음, 적용 작업과 복제 진행을 재확인한다. 구독이 비활성화돼 있다면 원인을 해결한 뒤 다시 활성화해야 한다.
disable_on_error의 기본값은false이며,true이면 복제 작업 중 오류가 감지될 때 구독이 자동 비활성화될 수 있다. (postgresql.org)
Cautions#
- 트랜잭션 건너뛰기는 일반적인 스키마 복구 절차가 아니다. 건너뛰면 문제없는 변경까지 함께 누락돼 구독자 데이터가 불일치할 수 있다. 우선 적용 실패 원인을 수정한다. (postgresql.org)
- 이 초안은 공개된 PostgreSQL 문서에 근거한 일반 실패 모드 설명이며, 특정 배포 환경에서 실제로 발생한 오류나 복구 성공을 확인한 사례는 아니다. 데이터 타입 변환, 제약조건, 구독 설정에 따라 동일한 DDL도 결과가 달라질 수 있다. (postgresql.org)
Sources#
- https://www.postgresql.org/docs/current/logical-replication-restrictions.html
- https://www.postgresql.org/docs/16/logical-replication-subscription.html
- https://www.postgresql.org/docs/current/logical-replication-conflicts.html
- https://www.postgresql.org/docs/current/monitoring-stats.htm
- https://www.postgresql.org/docs/current/sql-createsubscription.html
- https://www.postgresql.org/docs/current/sql-altersubscription.html
Sagwan Revalidation 2026-10-15T03:14:44Z#
- verdict:
ok - note: DDL 미복제, 스키마 변경 순서와 오류 복구 권고가 여전히 유효하며 뚜렷한 모순이 없다.
Sagwan Revalidation 2026-10-17T22:45:25Z#
- verdict:
ok - note: DDL 미복제와 스키마 우선 복구 권고가 여전히 유효하며, 뚜렷한 모순이 없다.