6.4 Replica clusters

지금까지의 복제와 failover는 하나의 Kubernetes 클러스터 안에서 일어나는 이야기였습니다. 그런데 클러스터 전체, 나아가 리전 하나가 통째로 사라지는 상황은 어떻게 대비할까요? CloudNativePG는 replica cluster로 이 문제를 풉니다. 다른 Kubernetes 클러스터나 리전에 있는 별도의 Cluster가 원본의 데이터를 계속 이어받아, 원본이 사라졌을 때 그 자리를 대신합니다.

replica cluster는 두 가지 용도로 나뉩니다. 하나는 재해 복구/고가용성을 위한 distributed topology, 다른 하나는 읽기 전용 워크로드 분산을 위한 standalone replica cluster입니다. 둘은 승격 방식에서 결정적으로 갈립니다.

.spec.replica stanza

replica cluster 동작은 .spec.replica 아래에서 정합니다. 주요 필드는 다음과 같습니다.

필드	의미
`enabled`	continuous recovery 모드 on/off (standalone에서 사용)
`source`	복제해 올 원본으로 참조할 external cluster 이름
`primary`	distributed topology에서 어느 Cluster가 primary인지 지정
`self`	자기 Cluster를 식별하는 선택적 이름
`minApplyDelay`	delayed replica의 지연 시간 (예: `'8h'`)
`promotionToken`	controlled switchover에 쓰는 base64 인코딩 체크포인트 데이터

원본과의 연결은 externalClusters에서 정의합니다. object store 플러그인, streaming 접속 정보, TLS 인증서를 함께 지정합니다.

externalClusters:
  - name: cluster-eu-south
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: cluster-eu-south
        serverName: cluster-eu-south
    connectionParameters:
      host: cluster-eu-south-rw.default.svc
      user: streaming_replica
      sslmode: verify-full
    sslKey:
      name: cluster-eu-south-replication
      key: tls.key
    sslCert:
      name: cluster-eu-south-replication
      key: tls.crt
    sslRootCert:
      name: cluster-eu-south-ca
      key: ca.crt

bootstrap: 원본에서 시작하기

replica cluster는 빈 상태에서 만들어지지 않습니다. 원본의 데이터를 먼저 가져와야 합니다. 세 가지 방법이 있습니다.

pg_basebackup

원본에 직접 네트워크로 붙어 baseline을 복제하고, 이후 streaming으로 계속 따라갑니다. 클러스터 간 네트워크 연결과 인증 정보가 필요합니다.

bootstrap:
  pg_basebackup:
    source: cluster-example
replica:
  enabled: true
  source: cluster-example

object store

S3·Azure Blob 등에 쌓인 WAL archive를 Barman Cloud 같은 플러그인으로 읽어 복원합니다. 리전 간 asynchronous 복제에 적합합니다.

bootstrap:
  recovery:
    source: cluster-example
replica:
  enabled: true
  source: cluster-example

snapshot

스토리지 인프라가 크로스 클러스터 snapshot을 지원할 때, snapshot으로 baseline을 만들고 streaming 또는 WAL 기반 continuous recovery로 이어 갑니다.

continuous recovery 자체는 streaming, WAL archive, 그리고 둘을 섞은 hybrid 중에서 고를 수 있습니다. hybrid에서는 PostgreSQL이 두 경로를 자동으로 오갑니다.

replica cluster의 세 가지 bootstrap 경로

distributed topology: 계획된 switchover

distributed topology는 여러 리전의 Cluster를 하나의 논리적 분산 데이터베이스로 묶습니다. 모든 Cluster가 같은 externalClusters 목록을 공유하고, 각자 replica.primary로 "지금 primary는 누구"인지를 가리킵니다. 계획된 전환(switchover)이 가능하다는 것이 standalone과의 결정적 차입니다.

전환은 demotion(강등)과 promotion(승격)을 짝지어 진행합니다. 먼저 옛 primary(cluster-eu-south)를 강등합니다.

# 옛 primary에 적용
replica:
  primary: cluster-eu-central   # primary를 상대로 지정
  source: cluster-eu-central

그러면 CloudNativePG는 shutdown checkpoint를 담은 WAL을 .partial 파일로 archive하고, status에 demotionToken(system identifier·timeline ID·REDO 위치를 담은 base64 JSON)을 만듭니다.

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

이 토큰을 새 primary가 될 Cluster(cluster-eu-central)에 promotionToken으로 넘기면서 primary를 자신으로 바꿉니다. 두 변경을 동시에 적용해야 합니다.

# 새 primary에 적용
replica:
  primary: cluster-eu-central
  promotionToken: <옛 primary에서 받은 DEMOTION_TOKEN>
  source: cluster-eu-south

경고

primary와 promotionToken은 반드시 함께 적용합니다. 토큰을 빠뜨리면 controlled switchover가 아니라 failover로 처리되어, 옛 primary를 다시 clone해야 하는 상황이 벌어집니다.

분산 토폴로지의 강등 토큰 전달과 계획 전환

standalone replica cluster

읽기 전용 워크로드 분산이 목적이라면 standalone으로 씁니다. distributed topology와 달리 여러 클러스터를 아우르는 분산 데이터베이스 개념이나 전역 primary 지정이 없습니다.

노트

standalone replica cluster의 승격은 되돌릴 수 없습니다. 한 번 promote하면 옛 primary는 controlled switchover로 되돌아오지 못하고 다시 clone해야 합니다. 계획된 전환이 필요하면 distributed topology를 씁니다.

복제를 영구히 끊고 독립된 클러스터로 떼어 내려면 enabled: false로 둡니다.

replica:
  enabled: false

delayed replica

실수로 지운 데이터를 되살릴 여지를 두기 위해, 일부러 복제를 늦추는 replica입니다. PostgreSQL의 recovery_min_apply_delay에 대응합니다.

replica:
  enabled: true
  source: cluster-example
  minApplyDelay: '8h'

경고

minApplyDelay는 promotionToken과 함께 쓸 수 없습니다. 지연 replica는 controlled switchover의 대상으로 삼지 않습니다.

정리

replica cluster는 다른 클러스터·리전에서 원본 데이터를 이어받아 재해에 대비하거나 읽기 부하를 분산합니다. bootstrap은 pg_basebackup(streaming)·object store recovery·volume snapshot 중에서 고르고, continuous recovery는 streaming/WAL/hybrid로 이어 갑니다.

distributed topology는 demotionToken↔promotionToken으로 계획된 switchover가 가능합니다. 토큰을 빠뜨리면 failover로 처리되어 재clone이 필요합니다
standalone replica cluster의 승격은 되돌릴 수 없습니다. 계획 전환이 필요하면 distributed topology를 씁니다

이것으로 복제와 고가용성 Part를 마칩니다.

.spec.replica stanza​

bootstrap: 원본에서 시작하기​

pg_basebackup​

object store​

snapshot​

distributed topology: 계획된 switchover​

standalone replica cluster​

delayed replica​

정리​