지금까지 PostgreSQL의 내부 메커니즘과 관련된 Wait Event를 알아보았습니다.
이번에는 PostgreSQL의 Replication에 대해 알아보고 이어서 관련된 Wait Event를 살펴보겠습니다. 본 문서에서는 Replication의 기본 동작 과정, 동기화 수준과 같이 Wait Event 발생과 관련된 개념만 중점적으로 설명합니다.
Replication의 구성 및 설정, 관련 카탈로그 등 보다 자세한 내용은 PostgreSQL Replication 시리즈를 통해 확인할 수 있습니다.
- PostgreSQL Replication > 종류 (👉🏻 바로가기)
- PostgreSQL Replication > 구성 (👉🏻 바로가기)
- PostgreSQL Replication > Trouble Shooting (👉🏻 바로가기)
- PostgreSQL Replication > Function (👉🏻 바로가기)
- PostgreSQL Replication > Catalog (👉🏻 바로가기)
- PostgreSQL Replication > 설정 확인 (👉🏻 바로가기)
- PostgreSQL Replication > Parameter (👉🏻 바로가기)
- PostgreSQL Replication > Slot (👉🏻 바로가기)
Replication
Replication은 하나의 Database에 저장된 데이터를 하나 이상의 다른 서버로 복제할 수 있도록 제공되는 기능으로 주로 다음과 같은 목적으로 사용됩니다.
- 고가용성 : 장애 발생 시 빠른 복구
- 부하 분산 : 읽기 작업 분산
- 백업 : 데이터 손실 방지
목적에 따라 세부적인 Replication 구성 방식은 달라질 수 있으며, 구성된 이후에는 여러 Server의 인프라 요소가 서로 밀접하게 연결됩니다.
본 문서에서는 Replication의 원본 서버를 Main Server, 복제 서버를 Standby Server로 표현합니다.
PostgreSQL Replication 종류
PostgreSQL에서 제공하는 대표적인 Replication 방식은 File-based Log Shipping, Streaming Replication, Logical Replication입니다. 모두 WAL(Write-Ahead Log)을 기반으로 동작하여 Main Server에서 생성된 WAL이 Standby Server로 전송되어 적용됩니다.
또한, 해당 방식들은 WAL을 적용하는 방식에 따라 Physical Replication과 Logical Replication으로 분류되기도 합니다.
구분 | WAL 적용 방식 | 종류 |
Physical Replication | WAL을 Byte 단위로 적용 | File-based Log Shipping, Streaming Replication |
Logical Replication | 논리적 단위(Table, Row)로 WAL을 적용 | Logical Replication |
Physical Replication은 Standby Server에서의 읽기 작업 가능 여부에 따라 Hot Standby와 Warm Standby로 구분되기도 합니다. 가능 여부는 hot_standby 파라미터로 조정할 수 있습니다.
- Hot Standby (hot_standby=
on) : Standby Server에서 Select 작업이 가능해 읽기 부하 분산 용도로 활용
- Warm Standby (hot_standby=
off) : WAL은 적용되지만 Query 작업은 불가능하며 주로 복구 목적으로 활용
File-based Log Shipping Replication
Main Server에서 생성된 WAL을 Archive File로 저장한 뒤 주기적으로 Standby Server로 전송하는 방식입니다.
- Main Server : WAL File이 가득 차면 새 파일로 전환됩니다. Archiver 프로세스는 archive_command 설정에 따라 가득 찬 WAL File을 지정 경로에 Archiving합니다.
- Standby Server : Startup 프로세스는 restore_command 설정에 따라 WAL File을 가져와 Database에 차례대로 적용합니다.
WAL File이 다 채워져야 전송되기 때문에 Main와 Standby 간 일정 수준의 동기화 지연이 발생합니다. 하지만 설정이 간단하고 네트워크가 불안정한 환경에서도 안정적으로 동작합니다.
Streaming Replication
WAL Record가 생성된 즉시 실시간으로 Standby Server에 Streaming되는 방식입니다.
- Main Server : WAL Sender 프로세스는 생성된 WAL Record를 실시간으로 읽어 전송합니다
- Standby Server : WAL Receiver 프로세스는 수신한 WAL Record를 WAL File에 저장하고, Startup 프로세스가 이를 읽어 Database에 적용합니다.
해당 방식은 WAL을 거의 실시간으로 적용할 수 있어 가장 많이 사용되는 방식입니다. Standby Server는 장애 복구뿐 아니라 실시간 데이터 읽기와 분석 용도로도 활용됩니다. 다만 네트워크 품질에 직접적인 영향을 받으므로 안정적인 네트워크 환경이 필요합니다.
Standby Server는 Cascading Replication으로 구성할 경우 WAL 수신자와 송신자 역할을 동시에 수행할 수 있습니다. Main Server로부터 받은 데이터를 다른 Standby Server(Downstream Server)로 재전송하는 중계 역할을 하는 구성입니다. Downstream Server 입장에서 Standby Server는 Main Server처럼 동작합니다.
Logical Replication
Logical Reaplication 방식은 게시(Publish)와 구독(Subscribe) 구조로 구현됩니다. 게시 역할을 하는 Server를 Publisher, 구독하는 Server를 Subscriber라고 부릅니다.
Server 간 전송되는 WAL은 Logical Decoding된 Table이나 Row 같은 논리적 객체이며 복제 대상을 선택적으로 지정할 수 있다는 점이 특징입니다.
- Main Server : Replication 대상 테이블이 Snapshot 형태로 Standby Server에 전송됩니다. 이후 테이블에 대해 생성된 WAL은 WAL Sender가 Logical Decoding 과정을 거쳐 전송됩니다.
- Standby Server : WAL Apply Worker 프로세스가 Decoding된 WAL을 수신해 직접 대상 테이블에 차례대로 적용합니다.
지정된 테이블은 최초 Snapshot으로 전송되고, 이후에는 변경 사항만 실시간 반영하며 트랜잭션 일관성을 유지합니다. 이러한 특징으로 인해 Transactional Replication이라고도 불립니다.
논리적으로 Decoding된 WAL Record를 전달함으로써, PostgreSQL 버전이나 플랫폼이 달라도 유연하게 데이터를 동기화할 수 있어 이기종 환경에서 활용도가 높습니다. 또한 Standby Server를 독립적인 Database로 취급할 수 있어 Read뿐 아니라 DML 작업도 처리할 수 있습니다.
Replication Slot
Replication Slot이란 WAL의 위치를 추적/관리하는 포인터로, Standby Server가 필요한 데이터를 모두 전송받을 때까지 Main Server의 WAL을 보존(삭제 방지)하기 위해 사용됩니다. 일시적 연결 중단 시에도 WAL 손실을 방지할 수 있습니다.
Streaming Replication과 Logical Replication에서 활용 가능하며 각각 Physical Replication Slot, Logical Replication Slot으로 명칭됩니다.
Replication 동기화
PostgreSQL Replication은 동기화 여부에 따라 Synchronous(동기) 와 Asynchronous(비동기) 방식으로 구분할 수도 있습니다. 설명한 세 가지 구성 방식 중 Streaming과 Logical Replication에서는 필요에 따라 두 가지 방식 중 하나를 선택 가능합니다.
- Synchronous Replication (동기 복제)
- Main Server에서 트랜잭션 Commit 수행 시 Standby Server의 응답 회신 후 완료 처리
- 데이터 일관성을 높은 수준으로 유지할 수 있으나 Commit 시간이 길어질 수 있음
- Asynchronous Replication (비동기 복제)
- Standby Server의 응답과 상관 없이 Main Server에서의 Commit 처리
- Commit 속도가 빠르나 장애 시 데이터 손실 가능성 있음
File-based Log Shipping Replication에서는 Main Server에서 하나의 WAL File이 모두 채워질 때까지 대기한 후 전송하므로 엄격한 의미의 동기화는 적용할 수 없습니다.
동기화 제어
PostgreSQL에서는 대표적으로 synchronous_commit, synchronous_standby_names 두 가지 파라미터를 조정하여 Replication 동기화 수준을 조정할 수 있습니다.
- synchronous_commit (Default:
on) - Client에 완료(Commit) 신호를 반환하기 전에 수행해야 하는 WAL 처리 단계를 지정하는 파라미터
- 가능한 값 : off, local, remote_write, on, remote_apply
- synchronous_standby_names
- Synchronous Replication 대상 Standby Server 목록
- 이 파라미터에 어떠한 대상도 입력되지 않으면 Asynchronous Replication으로 동작하며, 입력되면 synchronous_commit 파라미터 설정에 따라 동기화 수준이 달라짐
- 이 파라미터가 설정되지 않으면 synchronous_commit을 설정하더라도 제한적인 동작 내에서만 동기화 제어 가능
synchronous_commit 설정값 | 동기화 동작 |
off | Main Server에서의 Commit은 Main / Standby Server의 어떠한 응답도 기다리지 않고 즉시 완료됨
Commit 성능이 크게 개선되지만 WAL 손실 위험이 있음 |
off 이외 모든 값
(local, remote_write, on, remote_apply) | 모두 동일하게 동작. 최소한 Main Server에서의 WAL Flush는 대기한 후 Commit 완료됨 |
synchronous_commit 에 따른 동기화 동작
synchronous_standby_names 에 동기화 대상 Server 목록을 명시한 경우, synchronous_commit 값에 따라 세부적인 동작을 제어할 수 있습니다.
다음은 Main Server에서 Commit을 수행할 때, 명시된 Server 목록을 대상으로 적용되는 동기화 동작 4가지를 설명합니다.
① local
- Main Server에서의 WAL Flush까지만 대기
- Standby Server 응답 불필요 (실질적으로 Asynchronous Replication과 동일)
② remote_write
- Standby Server에서 WAL을 수신하여 디스크 Write가 완료될 때까지 대기. (Flush 이전)
③ on
- Standby Server에서 WAL을 수신하여 디스크 Write 및 Flush가 완료될 때까지 대기
④ remote_apply
- Standby Server에서 WAL이 실제 Database에 적용(Apply)될 때까지 대기
- 가장 강력한 동기화 수준
- Standby Server에서도 Main과 동일한 최신 데이터 즉시 조회 가능 (완전한 Synchronous Repliation)
synchronous_commit은 트랜잭션 단위로도 설정 가능하므로, 중요도에 따라 트랜잭션마다 다른 동기화 수준을 적용할 수 있습니다.
Replication Lag
Main↔Standby Server간 WAL 적용 시점의 차이를 Replication Lag(혹은 Data Lag)라고 합니다.
일반적으로 Replication Lag는 Server 간 WAL 적용 지연의 척도로 활용됩니다. 하지만 그 수치가 심각하게 커지면 Standby Server가 필요로 하는 WAL이 Main Server에서 삭제될 수 있고, 이 경우 Replication이 중단될 수 있으므로 지속적인 모니터링이 필요합니다.
Replication Lag가 발생하는 원인은 다음과 같습니다
- 네트워크 지연으로 WAL 전송이 느려지는 경우
- Standby Server의 리소스가 부족한 경우
- Standby에서 장시간 실행되는 Query가 있는 경우
PostgreSQL은 Replication Lag를 모니터링할 수 있도록 다양한 시스템 뷰를 제공합니다.
Catalog | 설명 | 조회 위치 |
pg_stat_replication | Replication에 대한 통계 정보 | Main |
pg_stat_wal_receiver | WAL Receiver에 대한 통계 정보 | Standby |
pg_replication_slots | 사용 중인 모든 Replication Slot에 대한 정보 | Main |
pg_stat_replication_slots | Logical Replication Slot에 대한 통계 정보 | Publisher |
pg_publication | Logical Replication에서 생성된 모든 Publication 정보 | Publisher |
pg_subscription | Logical Replication에서 생성된 모든 Subscription 정보 | Subscriber |
pg_stat_subscription | Logical Replication에서 Subscription에 대한 통계 정보 | Subscriber |
pg_stat_subscription_stats | Logical Replication에서 Subscriber에서 발생한 오류 정보 | Subscriber |
마무리
- PostgreSQL에서 대표적인 Replication 방식은 File-based Log Shipping, Streaming Replication, Logical Replication 이다.
- WAL 적용 방식에 따라 Physical Replication과 Logical Replication으로 구분되며 Physical Replication은 hot_standby 파라미터를 통해 Hot Standby와 Warm Standby 방식으로 세분화된다.
- Replication 동기화 수준에 따라 Asynchrnous Replication, Synchronous Replication으로 구분도 가능하며 synchronous_commit 과 synchronous_standby_names 파라미터로 동기화 동작을 제어할 수 있다.
- Main Server와 Standby Server간 WAL 적용 시점 차이를 Replication Lag라고 하며, pg_stat_replication, pg_stat_wal_receiver, pg_replication_slots 등 다양한 시스템 뷰를 제공해 Replication 상태를 모니터링할 수 있다.
함께 보면 좋은 아티클
