GN⁺: PostgreSQL Streaming Replication (WAL)은 무엇이고 어떻게 설정하는가
(mindhub365.com)- 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을 사용할 때는 네트워크 대역폭과 지연 시간을 고려해야 함. 마스터와 복제본 간의 데이터 전송은 네트워크 리소스를 상당히 소모할 수 있음. 복제본의 규모 확장성도 중요한 고려 사항
- 데이터 일관성 요구 사항도 평가해야 함. 동기식 복제는 쓰기 성능에 영향을 줄 수 있지만 더 강력한 일관성을 제공함. 비동기식 복제는 더 나은 성능을 제공하지만 데이터 손실 가능성이 약간 있음
Hacker News 의견
-
이 글은 훌륭하지만, 풀스택 개발자로서 데이터베이스를 관리하려는 관점에서 실제 적용 사례가 부족하다고 느끼는 의견이 있음
- 복제본이 마스터보다 얼마나 지연되고 있는지 확인하는 방법에 대한 질문이 있음
- 복제본을 모니터링하는 방법으로 간단한 cron 작업을 통해 상태를 확인하는 방법을 제안함
- 복잡한 문제로는 주 서버가 다운될 경우 복제본으로 전환하는 방법에 대한 질문이 있음
- 자동으로 전환할지 수동으로 전환할지에 대한 고민이 있음
- 스플릿 브레인 시나리오를 피하기 위해 두 개의 복제본이 필요한지에 대한 의문이 있음
- 전환 후 원래 상태로 복구하는 방법에 대한 질문이 있음
-
PostgreSQL 복제에 대한 가장 쉬운 솔루션은 Kubernetes 오퍼레이터라고 주장함
- 예로 CloudnativePG를 언급함
- 복제뿐만 아니라 장애 조치, 복구, 모니터링, 자동 복구, 백업 등이 필요하다고 설명함
- Kubernetes 외에 다른 무료/오픈 소스 구현이 있는지에 대한 질문이 있음
-
Kubernetes와 Helm을 사용하는 이유 중 하나로 이 문제를 해결할 수 있다고 봄
- Bitnami PostgreSQL 패키지를 통해 거의 추가 설정 없이 모든 것을 구성할 수 있다고 설명함
- Postgres-ha는 프록시를 생성하여 실패를 전문적으로 처리하여 무중단 장애 조치를 가능하게 한다고 설명함
-
Kubernetes 사용자에게 StackGres를 추천함
-
마지막으로, 이 글이 AI에 의해 작성된 것 같다는 회의적인 의견이 있음