Postgresql Replication (데이터베이스 이중화)

• Replication
  • Shared Disk Failover
    • 하나의 디스크를 여러 개의 PostgreSQL Server 가 공유하는 방식
  • File System Replication
    • 디스크는 별개로 사용하되 File System Level 로 복제하는 방식
  • Physical Replication
    • File-based Log Shipping
      • Warm Standby
      • Hot Standby
      • 장점
        • 다른 Replication 방식에 비해 구성이 간단
        • archive_command 파라미터를 이용하여 Standby Server 로 WAL 파일을 전송하기 쉬움
        • 다중 Standby Server 구성 가능
      • 단점
        • Major 버전과 Bit 가 모두 동일해야 구성 가능
        • WAL 파일이 가득 차거나(16mb), archive_timeout 에 의해 Switch 된 WAL 파일을 전송하므로 Main Server 장애 시 Switch 되지 않은 WAL 파일에 대한 Data 유실 가능성 존재
        • Standby Server 와 통신이 끊겨 WAL 파일이 전송되지 못한 채 삭제된 경우, WAL 파일 부재로 Replication 은 종료되며, Standby Server 를 재구성해야 함
        • Warm Standby 구성 시 Standby Server에 접속 및 Select 불가 (Hot Standby는 해당사항 없음)
    • Streaming Replication
      • Main Server 의 WAL 파일이 채워질 때까지 기다리지 않고 WAL Record 를 실시간으로 Streaming 하는 방식
      • 장점
        • 다른 Replication 방식에 비해 구성이 간단
        • File-based Log Shipping 방식에 비해 최신의 상태로 Standby Server 를 유지 가능
        • WAL Record 를 전달받는 방식으로, WAL 파일의 Switch 여부와 상관없이 Replication 가능
      • 단점
        • 아직 동기화되지 않은 WAL Record가 포함된 WAL 파일이 삭제된 경우, WAL Record 의 부재로 Replication 이 종료되면, Standby Server 의 재구성 필요
        • Main Server 를 계속 Streaming 해야 하므로 Main Server에 영향을 미칠 수 있음
    • 제약사항
      • Database 의 일부만 Replication 불가능(특정 Database 나 Table 에 대해서만 Replication 불가)
      • Standby Server 에서는 Write 작업 불가능
      • PostgreSQL 의 Major 버전이 다르다면 Replication 불가능
      • PostgreSQL 이 설치된 Platform 이 다르다면 Replication 불가능
  • Logical Replication
    • 여러 Database 를 단일 Database 로 통합
    • 서로 다른 Major 버전 간의 복제
    • 장점
      • 특정 Database 또는 Table 만 Replication 가능
      • Standby Server 에서 DDL, DML 등의 쓰기 작업 가능
      • 서로 다른 Major 버전, Platform 간 Replication 가능 (Migration 과 Upgrade 에 활용)
      • 구독자가 게시자가 되는 다중 형태 구성 가능
      • 구독에 대한 DML 유형(INSERT, UPDATE, DELETE, TRUNCATE)을 선택적으로 사용 가능
      • 구독에는 게시보다 많은 Column 정의가 가능하며 순서에 영향을 받지 않음. 단 Replication 되는 Column 의 Type 과 이름은 동일해야 함
    • 단점
      • Table 은 구독과 게시에서 동일한 이름을 사용해야 함
      • Table에는 기본키 또는 고유키가 존재해야 함
      • 양방향 Replication 불가능
      • Sequence, Large Objects, Materialized Views, Partition Root Table, Foreign Table 미지원
      • DML 작업에서만 지원되며 DDL 은 직접 수행
      • Replication 된 Data 가 제약 조건과 충돌하는 경우 Replication 이 중지되면 충돌 원인이 해결되어야 Replication 재개가 가능
  • ETC
    • Trigger-Based Primary-Standby Replication
    • SQL-Based Replication Middleware
    • Asynchronous Multimaster Replication
    • Synchronous Multimaster Replication

---

• Write-Ahead Log
  • 데이터무결성을 보장하는 DBMS 표준방법
    1. 변경내용을 설명하는 Log Record를 저장소에 먼저 기록
    2. 이후에 Data 파일에 변경내용을 적용하는 방식으로 동작
  • 사용하는 이유
    • Transaction Commit 마다 Data Page를 디스크에 기록할 필요가 없다.
    • Data Page 에 적용되지 않은 변경 내용은 Log Record 에서 실행 취소가 가능하다.
    • Log 파일은 순차적으로 작성되며, Log 파일 동기화 비용은 Data Page 쓰기 비용보다 훨씬 적다.
    • 소규모의 Transaction 을 대량으로 처리하는 경우, Log 파일의 fsync 하나로 여러 가지 Transaction 을 충분히 Commit 할 수 있다.
    • 온라인 백업 및 PITR(Point-In-Time Recovery) 지원이 가능하다.