레플리카 클러스터

원문 보기 위키 갱신 2026.10.03

레플리카 클러스터 (Replica clusters)

레플리카 클러스터는 다른 PostgreSQL 인스턴스(이상적으로는 역시 CloudNativePG가 관리하는)로부터 데이터를 복제하도록 설계된 CloudNativePG Cluster 리소스예요.

일반적으로 레플리카 클러스터는 다른 지역의 다른 쿠버네티스 클러스터에 배포돼요. 이러한 클러스터는 캐스케이딩 복제를 수행하도록 구성할 수 있고, 아래에서 자세히 설명하듯 소스에서 오브젝트 스토어로의 데이터 복제에 의존할 수 있어요.

레플리카 클러스터에는 주로 두 가지 사용 사례가 있어요:

재해 복구와 고가용성: 일반적으로 다른 지역에 위치한 서로 다른 쿠버네티스 클러스터를 가로질러 CloudNativePG 클러스터의 재해 복구와 어느 정도 고가용성을 향상시켜요. CloudNativePG 용어로는 "Distributed Topology"라고 알려져 있어요.
읽기 전용 워크로드: 리포팅 또는 온라인 분석 처리(Online Analytical Processing, OLAP) 같은 목적으로 PostgreSQL 클러스터의 독립형 레플리카를 만들어요. 이 레플리카는 주로 읽기 전용 워크로드용이에요. CloudNativePG 용어로는 "Standalone Replica Cluster"라고 불러요.

예를 들어 아래 다이어그램 — "Architecture" 섹션에서 가져온 것 — 은 두 개의 쿠버네티스 클러스터에 걸친 분산 PostgreSQL 토폴로지를 보여주며, 대칭 레플리카 클러스터가 주로 재해 복구 목적을 제공해요.

An example of multi-cluster deployment with a primary and a replica cluster

출처: 문서

본문

기본 개념 (Basic Concepts)

CloudNativePG는 PostgreSQL 복제 프레임워크 위에 구축되어, 이 섹션에서 설명하는 레플리카 클러스터 기능을 사용해 기존 소스 클러스터에서 PostgreSQL 클러스터를 만들고 동기화할 수 있게 해줘요. 소스는 프라이머리 클러스터일 수도 있고 다른 레플리카 클러스터(캐스케이딩 복제)일 수도 있어요.

PostgreSQL 역할에 관해 (About PostgreSQL Roles)

레플리카 클러스터는 연속 복구 모드로 동작하므로, 카탈로그와 역할이나 데이터베이스 같은 전역 객체를 포함한 데이터베이스에 대한 변경은 허용되지 않아요. 이러한 변경은 Cluster가 프라이머리로 전환될 때까지 연기돼요. 이 단계 동안 역할 같은 전역 객체는 소스 클러스터에 정의된 대로 유지돼요. CloudNativePG는 클러스터가 승격된 후 로컬 재정의를 적용해요.

클러스터를 승격할 계획이 없다면(예: 읽기 전용 워크로드) 또는 레플리카 클러스터가 승격된 후 소스 클러스터에서 완전히 분리할 의도라면, 아무 조치도 취할 필요가 없어요. 이것은 보통 "Standalone Replica Cluster"의 경우예요.

어떤 시점에 클러스터를 승격할 계획이라면, CloudNativePG는 레플리카 클러스터에서 프라이머리로 전환할 때 다음 역할과 비밀번호를 관리해요:

애플리케이션 사용자
슈퍼유저 (사용 중이라면)
선언적 인터페이스로 정의된 모든 역할

위 역할과 비밀번호가 변하지 않도록 원활히 보장하려면 각 Cluster에서 위 역할에 필요한 시크릿을 정의해야 해요. 이것은 보통 "Distributed Topology"의 경우예요.

레플리카 클러스터 부트스트래핑

첫 단계는 다음 방법 중 하나로 레플리카 클러스터를 부트스트랩하는 거예요:

pg_basebackup을 통한 스트리밍 복제
볼륨 스냅샷으로부터의 복구
오브젝트 스토어의 Barman Cloud 백업으로부터의 복구

pg_basebackup(스트리밍) 또는 복구(볼륨 스냅샷 또는 오브젝트 스토어)로 PostgreSQL 서버를 클로닝하는 자세한 지침은 "Bootstrap" 섹션을 참조하세요.

복제 구성하기

레플리카 클러스터의 베이스 백업이 준비되면 PostgreSQL 연속 복구를 사용해 오리진에서 변경이 어떻게 복제될지 정의해야 해요. 세 가지 주요 옵션이 있어요:

스트리밍 복제: 레플리카 클러스터와 소스 사이에 스트리밍 복제를 설정해요. 이 방법은 네트워크 연결을 구성하고 원활한 데이터 전송을 보장하기 위한 적절한 관리 및 보안 조치를 구현해야 해요.
WAL 아카이브: 오브젝트 스토어에 저장된 WAL(Write-Ahead Logging) 아카이브를 사용해요. WAL 파일은 소스 클러스터에서 오브젝트 스토어로 정기적으로 전송되며, 거기서 Barman Cloud 같은 CNPG-I 플러그인이 restore_command를 통해 레플리카 클러스터용으로 가져와요.
하이브리드 접근법: 스트리밍 복제와 WAL 아카이브 방법을 모두 결합해요. PostgreSQL은 데이터 일관성과 가용성을 보장하기 위해 필요에 따라 이 두 접근법을 관리하고 전환할 수 있어요.

:::warning[Cascading standbys and restore from WAL archive] 9.3 버전부터 존재한 PostgreSQL 버그가 캐스케이딩 스탠바이가 (restore_command 통한) WAL shipping 복제를 재개하는 것을 영구적으로 막을 수 있으며, requested starting point ... is ahead of the WAL flush position of this server 같은 오류로 실패하고 스스로 재시도하지 않아요. 이 버그는 PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24에서 수정됐어요. :::

외부 클러스터 정의하기

외부 클러스터를 구성할 때 다음과 같은 옵션이 있어요:

plugin 섹션:
- restore_job과 wal 프로토콜을 지원하는 CNPG-I 플러그인을 사용한 레플리카 클러스터 부트스트래핑을 활성화해요.
- CloudNativePG는 오브젝트 스토어에서 레플리카 클러스터를 부트스트랩할 수 있게 하는 Barman Cloud Plugin을 지원해요.
connectionParameters 섹션:
- pg_basebackup 섹션을 사용한 스트리밍 복제를 통한 레플리카 클러스터 부트스트래핑을 활성화해요.
- CloudNativePG는 지정된 프라이머리 인스턴스에서 primary_conninfo 옵션을 자동 설정해, WAL 수신자 프로세스를 시작해 소스 클러스터에 연결하고 데이터를 받게 해요.

여전히 barmanObjectStore 섹션에 접근할 수 있지만, 사용 중단되었어요:

WAL 아카이브 사용을 활성화하며, CloudNativePG가 지정된 프라이머리 인스턴스에서 restore_command를 자동 설정해요.
볼륨 스냅샷이 실현 가능하지 않을 때 recovery 섹션을 사용해 오브젝트 스토어에서 레플리카 클러스터를 부트스트랩할 수 있게 해요.

백업과 대칭 아키텍처

레플리카 클러스터는 지정된 프라이머리에서 예약된 오브젝트 스토어로 백업을 수행할 수 있어, 분산 환경에서 대칭 아키텍처를 지원해요. 이 아키텍처 선택은 통제된 데이터 센터 스위치오버 중 또는 예기치 않은 이벤트 후 장애 조치 중 승격을 위해 클러스터가 준비되도록 보장하므로 중요해요.

분산 아키텍처 유연성

PostgreSQL 데이터베이스를 위한 선호하는 분산 아키텍처를 설계할 자유가 있어요. 다음 중에서 선택해요:

사설 클라우드: 다른 데이터 센터의 여러 쿠버네티스 클러스터에 걸침.
공용 클라우드: 다른 지역의 여러 쿠버네티스 클러스터에 걸침.
하이브리드 클라우드: 사설과 공용 클라우드를 결합.
멀티 클라우드: 다른 지역과 Cloud Service Provider에 걸친 여러 쿠버네티스 클러스터에 걸침.

레플리카 클러스터 설정하기

소스 클러스터에서 레플리카 클러스터를 설정하려면 다음 단계에 따라 클러스터 YAML 파일을 만들고 그에 맞게 구성해요:

외부 클러스터 정의하기:
- externalClusters 섹션에서 레플리카 클러스터를 지정해요.
- 재해 복구(DR)와 고가용성(HA)을 목표로 하는 분산 PostgreSQL 토폴로지의 경우, 이 섹션은 분산 데이터베이스의 모든 PostgreSQL 클러스터에 대해 정의해야 해요.
레플리카 클러스터 부트스트랩하기:
- 스트리밍 부트스트랩: 스트리밍 복제를 통한 부트스트래핑에 pg_basebackup 섹션을 사용해요.
- 스냅샷/오브젝트 스토어 부트스트랩: 볼륨 스냅샷이나 오브젝트 스토어에서 부트스트랩하려면 recovery 섹션을 사용해요.
연속 복구 전략: 이를 .spec.replica stanza에서 정의해요:
- 분산 토폴로지: externalClusters에 정의된 분산 토폴로지와 함께 primary, source, self 필드를 사용해 구성해요. 이는 CloudNativePG가 승격 토큰(promotion token)을 사용해 프라이머리 클러스터의 강등과 이어진 레플리카 클러스터의 승격을 선언적으로 제어할 수 있게 해줘요.
- 독립형 레플리카 클러스터: enabled 옵션으로 연속 복구를 활성화하고 source 필드를 externalClusters 이름을 가리키게 설정해요. 이 구성은 주로 읽기 전용 워크로드용 레플리카를 만드는 데 적합해요.

연속 복구를 위한 Distributed Topology와 Standalone Replica Cluster 두 전략 모두 아래에서 철저히 설명돼요.

분산 토폴로지 (Distributed Topology)

분산 PostgreSQL 데이터베이스 계획하기

Dwight Eisenhower가 유명하게 말했듯, "계획이 전부다" — 이것은 쿠버네티스에서 PostgreSQL 아키텍처를 설계할 때도 마찬가지예요.

먼저 종이에 분산 토폴로지를 개념화한 다음 CloudNativePG API 구성으로 옮겨요. 이 구성은 주로 다음을 포함해요:

분산 PostgreSQL 설정의 모든 Cluster 정의에 포함되어야 하는 externalClusters 섹션.
.spec.replica stanza, 특히 primary, source, (선택적으로) self 필드.

예를 들어 남유럽과 중부 유럽에 위치한 두 개의 쿠버네티스 클러스터에 걸쳐 분산된 PostgreSQL 클러스터를 배포하고 싶다고 해볼게요.

이 시나리오에서 남유럽 쿠버네티스 클러스터에 CloudNativePG가 설치되어 있고, cluster-eu-south라는 PostgreSQL Cluster가 프라이머리 역할을 한다고 가정해요. 이 클러스터는 로컬 오브젝트 스토어로 연속 백업이 구성되어 있어요. 이 오브젝트 스토어는 중부 유럽 쿠버네티스 클러스터에 설치된 cluster-eu-central이라는 PostgreSQL Cluster도 접근할 수 있어요. 처음에 cluster-eu-central은 레플리카 클러스터로 기능해요. 대칭 접근법에 따라 연속 백업용 로컬 오브젝트 스토어도 가지며, 이를 cluster-eu-south가 읽어야 해요.

이 예시에서 복구는 두 클러스터 사이의 어떤 스트리밍 복제 없이 오로지 WAL shipping을 통해서만 수행돼요. 하지만 스트리밍 복제만 사용하거나 WAL shipping을 폴백으로 하는 하이브리드 접근법 — 스트리밍 복제를 채택하도록 설정을 구성할 수 있어요. "Configuring replication" 섹션에서 설명했죠.

두 Cluster 리소스에 대한 externalClusters 섹션을 오브젝트 스토어용 Barman Cloud Plugin에 의존해 다음과 같이 구성할 거예요:

# Distributed topology configuration
externalClusters:
  - name: cluster-eu-south
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: cluster-eu-south
        serverName: cluster-eu-south
  - name: cluster-eu-central
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: cluster-eu-central
        serverName: cluster-eu-central

cluster-eu-south PostgreSQL 프라이머리 Cluster에 대한 .spec.replica stanza는 다음과 같이 구성해야 해요:

replica:
  primary: cluster-eu-south
  source: cluster-eu-central

한편 cluster-eu-central PostgreSQL 레플리카 Cluster에 대한 .spec.replica stanza는 다음과 같이 구성해야 해요:

replica:
  primary: cluster-eu-south
  source: cluster-eu-south

이 구성에서 primary 필드가 Cluster 리소스의 이름(또는 다른 것을 사용한다면 .spec.replica.self)과 일치하면 현재 클러스터는 분산 토폴로지에서 프라이머리로 간주돼요. 그렇지 않으면 source에서(이 경우 Barman 오브젝트 스토어를 사용해) 레플리카로 설정돼요.

이 설정을 통해 여러 쿠버네티스 클러스터에 걸친 분산 PostgreSQL 아키텍처를 효율적으로 관리할 수 있으며, 선언적 구성을 사용해 프라이머리 PostgreSQL 클러스터의 통제된 스위치오버로 고가용성과 재해 복구를 모두 보장해요.

분산 토폴로지에서 통제된 스위치오버는 다음을 포함하는 두 단계 프로세스예요:

프라이머리 클러스터를 레플리카 클러스터로 강등
레플리카 클러스터를 프라이머리 클러스터로 승격

이 프로세스들은 다음 섹션에서 설명돼요.

:::info[Important] 진행하기 전에 위의 "About PostgreSQL Roles" 섹션을 검토하고, 분산 토폴로지에 참여하는 모든 Cluster 객체에서 시크릿을 포함한 동일한 역할 정의를 사용하세요. :::

프라이머리를 레플리카 클러스터로 강등하기

CloudNativePG는 프라이머리 클러스터를 레플리카 클러스터로 강등하는 기능을 제공해요. 이 작업은 일반적으로 프라이머리 역할을 한 데이터 센터에서 다른 데이터 센터로 전환할 때 계획돼요. 이 과정은 현재 프라이머리 클러스터(예: cluster-eu-south)를 레플리카 클러스터로 강등하고, 완전히 동기화되었을 때 지정된 레플리카 클러스터(예: cluster-eu-central)를 프라이머리로 승격하는 것을 포함해요.

현재 프라이머리 Cluster 리소스에 새 프라이머리가 될 레플리카 클러스터를 가리키는 외부 클러스터를 정의했다면, primary 필드를 다음과 같이 바꾸기만 하면 돼요:

replica:
  primary: cluster-eu-central
  source: cluster-eu-central

프라이머리 PostgreSQL 클러스터가 강등되면 쓰기 작업은 더 이상 가능하지 않아요. 그러면 CloudNativePG는:

종료 체크포인트를 포함한 WAL 파일을 WAL 아카이브에 .partial 파일로 보관해요.
pg_controldata의 관련 정보(시스템 식별자, 타임스탬프, 타임라인 ID, REDO 위치, 최신 체크포인트의 REDO WAL 파일 등)를 포함하는 base64 인코딩 JSON 구조인 demotionToken을 상태에 생성해요.

첫 단계는 연속 복구 프로세스를 (스트리밍 복제 없이) 오로지 WAL 아카이브만으로 강등/승격하는 데 필요해요.

두 번째 단계인 .status.demotionToken 생성은 데이터 손실 없이, 그리고 이전 프라이머리를 재구축하지 않고 원활한 강등/승격 프로세스를 보장해요.

이 시점에 이전 프라이머리는 레플리카 클러스터로 전환되어, 새 글로벌 프라이머리: cluster-eu-central에서 WAL 데이터를 기다려요.

다른 클러스터 승격을 진행하려면 다음 명령으로 cluster-eu-south에서 demotionToken을 검색해야 해요:

kubectl get cluster cluster-eu-south \
  -o jsonpath='{.status.demotionToken}'

클러스터 상태를 확인해 cnpg 플러그인으로 demotionToken을 얻을 수 있어요. 토큰은 Demotion token 섹션 아래에 나열돼요.

:::note cluster-eu-south에서 얻은 demotionToken은 cluster-eu-central의 promotionToken으로 사용돼요. :::

클러스터 상태를 확인해 cnpg 플러그인으로 역할 변경을 검증할 수 있어요:

kubectl cnpg status cluster-eu-south

레플리카를 프라이머리 클러스터로 승격하기

PostgreSQL 레플리카 클러스터(예: cluster-eu-central)를 프라이머리 클러스터로 승격하고 지정된 프라이머리를 실제 프라이머리 인스턴스로 만들려면 다음 단계를 동시에 수행해야 해요:

.spec.replica.primary를 승격할 현재 레플리카 클러스터의 이름(예: cluster-eu-central)으로 설정해요.
이전 프라이머리 클러스터에서 얻은 값으로 .spec.replica.promotionToken을 설정해요 ("Demoting a Primary to a Replica Cluster" 참조).

cluster-eu-central의 스펙에서 업데이트된 replica 섹션은 다음과 같아야 해요:

replica:
  primary: cluster-eu-central
  promotionToken: <PROMOTION_TOKEN>
  source: cluster-eu-south

:::warning primary와 promotionToken 필드에 변경을 동시에 적용하는 것이 중요해요. 승격 토큰이 생략되면 장애 조치가 트리거되어 이전 프라이머리의 재구축이 필요해져요. :::

이러한 조정 후 CloudNativePG는 레플리카 클러스터의 프라이머리 클러스터로의 승격을 시작해요. 처음에 CloudNativePG는 지정된 프라이머리 클러스터가 토큰에 포함된 지정된 Log Sequence Number(LSN)까지 모든 Write-Ahead Logging(WAL) 정보를 복제할 때까지 기다려요. 이 목표가 달성되면 승격 프로세스가 시작돼요. 새 프라이머리 클러스터는 타임라인을 전환하고 history 파일과 새 WAL을 보관함으로써 cluster-eu-south 클러스터의 복제 프로세스를 차단 해제하며, 이 클러스터는 이후 레플리카로 동작해요.

역할 변경을 검증하려면 cnpg 플러그인으로 클러스터 상태를 확인하세요:

kubectl cnpg status cluster-eu-central

이 명령은 cluster-eu-central의 현재 상태를 제공해 프라이머리로의 승격을 확인해줘요.

이 단계들을 따르면 원활하고 통제된 승격 프로세스를 보장하여 중단을 최소화하고 PostgreSQL 클러스터 전반의 데이터 무결성을 유지할 수 있어요.

독립형 레플리카 클러스터 (Standalone Replica Clusters)

:::info[Important] Standalone Replica Clusters는 CloudNativePG 1.24에서 Distributed Topology 전략이 도입되기 전에는 Replica Clusters로 알려져 있었어요. :::

CloudNativePG에서 Standalone Replica Cluster는 다음과 같은 구성으로 연속 복구 상태에 있는 PostgreSQL 클러스터예요:

.spec.replica.enabled가 true로 설정됨
.spec.replica.source 필드를 통해 정의된 물리적 복제 소스가 externalClusters 이름을 가리킴

.spec.replica.enabled가 false로 설정되면 레플리카 클러스터는 연속 복구 모드를 종료하고 프라이머리 클러스터가 되어, 원래 소스에서 완전히 분리돼요.

:::warning 복제 비활성화는 되돌릴 수 없는 작업이에요. 복제가 비활성화되고 레플리카 클러스터의 지정된 프라이머리 인스턴스가 프라이머리로 승격되면, 레플리카 클러스터와 소스 클러스터는 definitively 두 개의 독립적인 클러스터가 돼요. :::

:::info[Important] 독립형 레플리카 클러스터는 주로 읽기 전용 워크로드를 포함한 여러 사용 사례에 적합해요. 재해 복구 솔루션을 설정할 계획이라면 위의 "Distributed Topology"를 살펴보세요. :::

분산 토폴로지와의 주요 차이점

Standalone Replica Clusters는 재해 복구 목적으로 사용될 수 있지만, "Distributed Topology" 전략과 여러 핵심 측면에서 다르다:

분산 데이터베이스 개념 부재: Standalone Replica Clusters는 단순한 형태(두 클러스터) 또는 더 복잡한 구성(예: 원형 토폴로지의 세 클러스터) 모두에서 분산 데이터베이스의 개념을 지원하지 않아요.
글로벌 프라이머리 클러스터 없음: Standalone Replica Clusters에는 글로벌 프라이머리 클러스터라는 개념이 없어요.
통제된 스위치오버 없음: Standalone Replica Cluster는 프라이머리로만 승격될 수 있어요. 통제된 스위치오버가 불가능하므로 이전 프라이머리 클러스터는 재클로닝해야 해요.

장애 조치는 두 전략에서 동일하며, 이전 프라이머리가 다시 올라오면 재클로닝이 필요해요.

`pg_basebackup`을 사용한 독립형 레플리카 클러스터 예시

이 첫 번째 예시는 부트스트랩과 연속 복구 둘 다에서 스트리밍 복제를 사용하는 독립형 레플리카 클러스터를 정의해요. 레플리카 클러스터는 TLS 인증을 사용해 소스 클러스터에 연결돼요.

sample/ 하위 디렉토리의 샘플 YAML을 확인할 수 있어요.

소스 클러스터를 가리키는 bootstrap과 replica 섹션을 주의하세요.

  bootstrap:
    pg_basebackup:
      source: cluster-example

  replica:
    enabled: true
    source: cluster-example

이전 구성은 애플리케이션 데이터베이스와 소유 사용자가 기본값인 app으로 설정되어 있다고 가정해요. 복원 중인 PostgreSQL 클러스터가 다른 이름을 사용한다면, Configure the application database에 문서화된 대로 지정해야 해요. 또한 원래 클러스터의 애플리케이션 사용자 시크릿을 복사해 소스와 동기화 상태로 유지하는 것을 고려해야 해요. 자세한 내용은 "About PostgreSQL Roles"을 참조하세요.

externalClusters 섹션에서 connectionParameters 하위 섹션의 호스트에 올바른 네임스페이스를 사용하는 것을 기억하세요. 레플리카 클러스터가 별도 네임스페이스에 있다면 필요에 따라 -replication과 -ca 시크릿을 복사했어야 해요.

  externalClusters:
  - name: <MAIN-CLUSTER>
    connectionParameters:
      host: <MAIN-CLUSTER>-rw.<NAMESPACE>.svc
      user: streaming_replica
      sslmode: verify-full
      dbname: postgres
    sslKey:
      name: <MAIN-CLUSTER>-replication
      key: tls.key
    sslCert:
      name: <MAIN-CLUSTER>-replication
      key: tls.crt
    sslRootCert:
      name: <MAIN-CLUSTER>-ca
      key: ca.crt

오브젝트 스토어에서의 독립형 레플리카 클러스터 예시

두 번째 예시는 recovery 섹션을 사용해 오브젝트 스토어에서 부트스트랩하고 스트리밍 복제와 주어진 오브젝트 스토어 둘 다로 연속 복구하는 레플리카 클러스터를 정의해요. 스트리밍 복제의 경우 레플리카 클러스터는 기본 인증(basic authentication)을 사용해 소스 클러스터에 연결해요.

sample/ 하위 디렉토리에서 샘플 YAML을 확인할 수 있어요.

소스 클러스터를 가리키는 bootstrap과 replica 섹션을 주의하세요.

  bootstrap:
    recovery:
      source: cluster-example

  replica:
    enabled: true
    source: cluster-example

externalClusters 섹션에서 endpointURL과 connectionParameters.host에 올바른 네임스페이스를 사용하도록 주의하세요. 필요한 경우 필요한 시크릿이 복사되었는지, 그리고 소스 클러스터의 백업이 이미 생성되었는지 확인하세요.

  externalClusters:
  - name: <MAIN-CLUSTER>
    # Example with Barman Cloud Plugin
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: <MAIN-CLUSTER>
        serverName: <MAIN-CLUSTER>
        …
    connectionParameters:
      host: <MAIN-CLUSTER>-rw.default.svc
      user: postgres
      dbname: postgres
    password:
      name: <MAIN-CLUSTER>-superuser
      key: password

:::note 소스 클러스터와 레플리카 클러스터 사이에 스트리밍 복제를 사용하려면 두 클러스터 사이에 네트워크 연결이 있고, 비밀번호나 인증서를 보유한 모든 필요한 시크릿이 사전에 제대로 생성되어 있는지 확인해야 해요. :::

볼륨 스냅샷을 사용한 예시

볼륨 스냅샷을 사용하고 스토리지 클래스가 크로스 클러스터 스냅샷 가용성을 제공한다면, 소스 클러스터의 볼륨 스냅샷을 통해 레플리카 클러스터를 부트스트랩하는 데 활용할 수 있어요.

세 번째 예시는 recovery 섹션을 사용해 볼륨 스냅샷에서 부트스트랩하는 레플리카 클러스터를 정의해요. WAL 파일을 가져오기 위해 스트리밍 복제((기본 인증을 통한))와 오브젝트 스토어를 사용해요.

sample/ 하위 디렉토리에서 샘플 YAML을 확인할 수 있어요.

예시는 애플리케이션 데이터베이스와 소유 사용자가 기본값인 app으로 설정되어 있다고 가정해요. 복원 중인 PostgreSQL 클러스터가 다른 이름을 사용한다면, Configure the application database에 문서화된 대로 지정해야 해요. 또한 원래 클러스터의 애플리케이션 사용자 시크릿을 복사해 소스와 동기화 상태로 유지하는 것을 고려해야 해요. 자세한 내용은 "About PostgreSQL Roles"을 참조하세요.

지연 레플리카 (Delayed replicas)

CloudNativePG는 .spec.replica.minApplyDelay 옵션을 통해 지연 레플리카 생성을 지원하며, PostgreSQL의 recovery_min_apply_delay를 활용해요.

지연 레플리카는 의도적으로 프라이머리 데이터베이스보다 지정된 시간만큼 늦어지도록 설계됐어요. 이 지연은 PostgreSQL의 기본 recovery_min_apply_delay 파라미터에 매핑되는 .spec.replica.minApplyDelay 옵션으로 구성 가능해요.

지연 레플리카의 주요 목표는 프라이머리 데이터베이스에 대한 의도치 않은 SQL 문장 실행의 영향을 완화하는 거예요. 이는 적절한 WHERE 절 없이 UPDATE 또는 DELETE 같은 작업이 수행되는 시나리오에서 특히 유용해요.

레플리카 클러스터에서 지연을 구성하려면 .spec.replica.minApplyDelay 옵션을 조정해요. 이 파라미터는 레플리카가 프라이머리보다 얼마나 늦어질지 결정해요. 예를 들어:

  # ...
  replica:
    enabled: true
    source: cluster-example
    # Enforce a delay of 8 hours
    minApplyDelay: '8h'
  # ...

위 예시는 문제가 레플리카로 전파되기 전에 감지하고 수정할 8시간의 버퍼 기간을 제공해 우발적인 데이터 수정으로부터 보호하는 데 도움을 줘요.

복구 시간 목표와 의도치 않은 프라이머리 데이터베이스 작업의 잠재적 영향에 따라 지연을 모니터링하고 필요에 따라 조정하세요.

지연 레플리카의 주요 사용 사례는 다음과 같이 요약할 수 있어요:

인간 오류 완화: 프라이머리 데이터베이스에서 의도치 않은 SQL 작업으로 인한 데이터 손상 또는 손실의 위험을 줄임
복구 시간 최적화: 변경이 다른 레플리카에 적용되기 전에 문제를 식별하고 시정할 수 있는 지연 레플리카를 가짐으로써 의도치 않은 변경으로부터 더 빠른 복구를 용이하게 함
향상된 데이터 보호: 원치 않는 변경의 전파를 방지하기 위해 개입할 기회를 제공하는 시간 버퍼를 도입해 중요 데이터를 보호함

:::warning 지연 레플리카의 minApplyDelay 옵션은 promotionToken과 함께 사용할 수 없어요. :::

지연 레플리카를 복제 전략에 통합하면 PostgreSQL 환경의 복원력과 데이터 보호 기능을 향상시킬 수 있어요. 특정 요구사항과 데이터의 중요도에 따라 지연 기간을 조정하세요.

:::info[Important] 항상 목표를 측정하세요. 환경에 따라 더 빠른 결과를 위해 볼륨 스냅샷 기반 복구에 의존하는 것이 더 효율적일 수 있어요. 여러분의 고유한 요구사항과 인프라에 가장 잘 맞는 접근법을 평가하고 선택하세요. :::