4P by neo 5달전 | ★ favorite | 댓글 1개
  • 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.confpostgresql.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에 의해 작성된 것 같다는 회의적인 의견이 있음