6.4 Replica clusters

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

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

    flowchart TD
  subgraph EUS["리전 A (primary)"]
    P["primary Cluster"]
  end
  subgraph EUC["리전 B (replica)"]
    R["replica Cluster"]
  end
  OBJ["object store<br/>(WAL archive)"]

  P -->|"WAL archive"| OBJ
  OBJ -.->|"continuous recovery"| R
  P -->|"streaming"| R
  

.spec.replica stanza

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

원본과의 연결은 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는 빈 상태에서 만들어지지 않는다. 원본의 데이터를 먼저 가져와야 한다. 세 가지 방법이 있다.

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

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

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

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

standalone replica cluster

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

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

replica:
  enabled: false

delayed replica

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

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

정리

• 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를 마친다. 다음 Part(백업과 복구)에서는 object store와 volume snapshot을 이용한 백업, WAL archiving, 그리고 특정 시점으로 되돌리는 PITR를 본다.