# PostgreSQL Streaming Replication (WAL)은 무엇이고 어떻게 설정하는가

> Clean Markdown view of GeekNews topic #17218. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=17218](https://news.hada.io/topic?id=17218)
- GeekNews Markdown: [https://news.hada.io/topic/17218.md](https://news.hada.io/topic/17218.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-10-14T09:43:54+09:00
- Updated: 2024-10-14T09:43:54+09:00
- Original source: [mindhub365.com](https://mindhub365.com/sql/postgresql-streaming-replication-wal-what-it-is-and-how-to-configure-one/)
- Points: 4
- Comments: 1

## Topic Body

- PostgreSQL의 Streaming Replication은 프라이머리 DB의 실시간에 가까운 복제본을 하나 이상의 스탠바이 서버에서 유지하는 효율적인 방법  
- 프라이머리 서버는 Write-Ahead Log (WAL) 레코드를 생성되는 대로 스탠바이 서버로 지속적으로 전송하여 복제 과정의 지연을 최소화  
- 고가용성과 확장성 향상을 위해 설계되어 읽기 쿼리를 스탠바이 서버로 오프로드하여 프라이머리 서버의 부하를 줄일 수 있음  
- 동기식과 비동기식 모드를 모두 지원하여 데이터 일관성과 성능의 균형을 유연하게 조절 가능  
- 스탠바이 서버가 프라이머리에 연결하여 WAL 스트리밍을 요청하고, 수신한 레코드를 자체 DB 사본에 적용하는 과정 포함  
- 파일 기반 로그 전송에 비해 더 빠른 장애 조치와 데이터 손실 위험 감소를 제공하여 지리적으로 분산된 환경에 이상적  
  
### Streaming Replication은 어떻게 동작하나?  
  
- 프라이머리 서버에서 스탠바이 서버로 WAL 데이터를 실시간으로 지속적으로 전송하여 스탠바이의 DB를 프라이머리와 거의 동일하게 유지  
- 이는 마스터 장애 조치 또는 읽기 작업 처리를 위해 복제본을 사용할 수 있어 시스템이 몇 배의 규모로 확장 가능  
  
### PostgreSQL 설정 파일 및 위치  
- PostgreSQL 구성 파일은 데이터베이스 서버의 설정과 동작을 관리하는 데 중요한 역할을 함.  
  - `postgresql.conf`: 대부분의 서버 설정이 포함된 주요 설정 파일. 운영 체제에 따라 `/etc/postgresql/<version>/main/postgresql.conf` (Debian/Ubuntu) 또는 `/var/lib/pgsql/<version>/data/postgresql.conf` (Red Hat/CentOS)와 같은 다양한 위치에 있음  
  - `pg_hba.conf`: 클라이언트 인증을 제어하여 클라이언트가 서버에 연결하는 방법 정의. 일반적으로 `postgresql.conf`와 동일한 디렉토리에 위치  
  - `pg_ident.conf`: 사용자 이름 매핑에 사용되지만 덜 자주 사용됨  
  - `recovery.conf`: PostgreSQL 12 이전 버전에서 스탠바이 서버 구성에 사용되었지만, 이후 버전에서는 `postgresql.conf`와 `postgresql.auto.conf`로 내용이 이동됨  
- 정확한 위치는 운영 체제, 설치 방법, PostgreSQL 버전에 따라 다를 수 있음  
  - `SHOW config_file;` SQL 명령을 사용하여 PostgreSQL 인스턴스 내에서 이러한 파일의 위치를 찾을 수 있음  
  
### WAL(Write Ahead Logs) 예제 및 구조  
  
- `pg_waldump` 명령으로 WAL을 볼 수 있음  
- 각 줄은 DB 작업에 대한 정보가 포함된 WAL 레코드를 나타냄  
- 각 레코드의 구성 요소:  
  - rmgr: 리소스 관리자(예: Heap, Btree, Transaction)   
  - len: 레코드 길이  
  - tx: 트랜잭션 ID  
  - lsn: 로그 시퀀스 번호   
  - prev: 이전 LSN  
  - desc: 작업 설명  
- 보이는 작업 유형:   
  - INSERT 작업(Heap 및 Btree)  
  - MULTI_INSERT 작업(Heap2)   
  - COMMIT 트랜잭션  
  - 파일 작업(CREATE)  
  - Full Page Writes(FPW)  
- WAL 출력은 트랜잭션 흐름, 데이터 수정, 시스템 활동을 세부적으로 보여주어 DB 동작 분석, 문제 해결, 시점 복구에 유용  
  
### Docker로 작업하는 방법  
  
- `postgresql.conf`에서 Streaming Replication 관련 중요 설정:  
  - wal_level, max_wal_senders, max_replication_slots, hot_standby 등   
- Docker Compose 예제에 필요한 것:  
  - `init-master.sh`: PostgreSQL 마스터를 복제용으로 설정. 복제 사용자와 슬롯 생성, WAL 관련 설정 업데이트  
  - `init-replica.sh`: 마스터에 연결하고 복제를 시작하도록 PostgreSQL 복제본 준비. 마스터가 준비될 때까지 대기한 후 기본 백업 수행, 복제본 구성  
  - `start-replica.sh`: Docker 컨테이너에서 PostgreSQL 복제본 시작. `init-replica.sh` 스크립트 실행 후 PostgreSQL 시작  
  - `docker-compose.yml`: 마스터와 복제본 서비스를 정의하고 필요한 환경 변수, 볼륨, 명령 등을 설정  
- 스크립트에 실행 권한 부여 후 `docker-compose up -d` 실행하면 마스터와 복제본이 시작됨  
- 마스터에 연결하여 `pg_stat_replication`으로 복제 상태 확인 가능  
- 복제본에 연결하여 `pg_is_in_recovery()`로 복구 모드인지 확인 가능  
  
### GN⁺의 의견   
  
- Streaming Replication은 데이터베이스 인프라의 성능과 복원력을 크게 향상시킬 수 있음. 장애 조치 시나리오에 대비하거나 복제본에 읽기 부하를 분산시키는 경우 이를 통해 DB가 확장 및 안정적인 성능을 보장할 수 있음   
- 전체 구성 프로세스와 출력을 보여주는 것은 중요함. 이는 많은 이동 부분에 대한 종합적인 관점을 제공하고 무슨 일이 일어나고 있는지 더 잘 이해할 수 있게 해줌  
- Streaming Replication이 어떻게 작동하는지 이해하고 올바르게 구성하는 것은 매우 중요함. 이 글이 이 과정을 명확히 하고 복제가 어떻게 동작하는지에 대한 통찰력을 제공했기를 바람  
- 유사한 기능을 가진 다른 제품이나 프로젝트로는 MySQL의 Replication이나 Oracle의 Data Guard가 있음. 이러한 솔루션들도 마스터에서 변경 사항을 복제본으로 전송하는 방식으로 작동하지만 구현 세부 사항은 다를 수 있음  
- Streaming Replication을 사용할 때는 네트워크 대역폭과 지연 시간을 고려해야 함. 마스터와 복제본 간의 데이터 전송은 네트워크 리소스를 상당히 소모할 수 있음. 복제본의 규모 확장성도 중요한 고려 사항  
- 데이터 일관성 요구 사항도 평가해야 함. 동기식 복제는 쓰기 성능에 영향을 줄 수 있지만 더 강력한 일관성을 제공함. 비동기식 복제는 더 나은 성능을 제공하지만 데이터 손실 가능성이 약간 있음

## Comments



### Comment 30006

- Author: neo
- Created: 2024-10-14T09:43:54+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41818446) 
- 이 글은 훌륭하지만, 풀스택 개발자로서 데이터베이스를 관리하려는 관점에서 실제 적용 사례가 부족하다고 느끼는 의견이 있음
  - 복제본이 마스터보다 얼마나 지연되고 있는지 확인하는 방법에 대한 질문이 있음
  - 복제본을 모니터링하는 방법으로 간단한 cron 작업을 통해 상태를 확인하는 방법을 제안함
  - 복잡한 문제로는 주 서버가 다운될 경우 복제본으로 전환하는 방법에 대한 질문이 있음
  - 자동으로 전환할지 수동으로 전환할지에 대한 고민이 있음
  - 스플릿 브레인 시나리오를 피하기 위해 두 개의 복제본이 필요한지에 대한 의문이 있음
  - 전환 후 원래 상태로 복구하는 방법에 대한 질문이 있음

- PostgreSQL 복제에 대한 가장 쉬운 솔루션은 Kubernetes 오퍼레이터라고 주장함
  - 예로 CloudnativePG를 언급함
  - 복제뿐만 아니라 장애 조치, 복구, 모니터링, 자동 복구, 백업 등이 필요하다고 설명함
  - Kubernetes 외에 다른 무료/오픈 소스 구현이 있는지에 대한 질문이 있음

- Kubernetes와 Helm을 사용하는 이유 중 하나로 이 문제를 해결할 수 있다고 봄
  - Bitnami PostgreSQL 패키지를 통해 거의 추가 설정 없이 모든 것을 구성할 수 있다고 설명함
  - Postgres-ha는 프록시를 생성하여 실패를 전문적으로 처리하여 무중단 장애 조치를 가능하게 한다고 설명함

- Kubernetes 사용자에게 StackGres를 추천함

- 마지막으로, 이 글이 AI에 의해 작성된 것 같다는 회의적인 의견이 있음