본문으로 건너뛰기

6.3 Rolling updates

PostgreSQL 이미지를 새 마이너 버전으로 올리거나, restart가 필요한 설정을 바꾸거나, Operator 자체를 업그레이드할 때 인스턴스를 다시 띄워야 합니다. 이때 모든 pod를 한꺼번에 내리면 서비스가 멈춥니다. CloudNativePG는 그 대신 rolling update로 인스턴스를 하나씩 교체해 서비스 중단을 최소화합니다.

핵심 원칙은 단순합니다. replica부터 하나씩 바꾸고, primary는 맨 마지막에 switchover로 넘깁니다. 읽기 트래픽은 살아 있는 다른 인스턴스가 받고, 쓰기 중단은 primary가 교체되는 짧은 switchover 순간으로 국한됩니다.

무엇이 rolling update를 부르나​

다음 변화가 감지되면 Operator가 rolling update를 시작합니다.

  • imageName 변경 (예: PostgreSQL 마이너 버전 업)
  • .spec.postgresql.extensions stanza 변경
  • Image Catalog에 해당 major 버전의 새 이미지가 올라옴
  • restart가 필요한 PostgreSQL 설정 변경
  • .spec.resources 값 변경
  • Operator 업그레이드 (in-place instance manager 업데이트가 켜져 있지 않은 경우)

교체 순서​

Operator는 serial 번호가 가장 높은 replica부터 한 번에 pod 하나씩 올려 나가고, primary는 가장 마지막에 처리합니다. pod는 삭제 후 재생성되지만 PVC는 그대로 유지되므로, 데이터를 다시 clone하지 않고 같은 CloudNativePG 신원을 유지한 채 이미지만 갈아 끼웁니다.

primaryUpdateStrategy: primary를 언제 넘길까​

replica 교체가 끝난 뒤 primary를 어떻게 처리할지는 primaryUpdateStrategy가 정합니다.

unsupervised​

unsupervised (기본값) — 전 과정이 자동입니다. replica 업그레이드가 끝나면 primaryUpdateMethod가 알아서 실행되어 primary까지 교체합니다. 대부분의 환경에 적합합니다.

supervised​

supervised — replica 업그레이드까지만 하고 멈춘 뒤, primary 전환은 DBA의 수동 개입을 기다립니다. 전환 시점을 트래픽이 적은 시간대로 직접 고르고 싶을 때 씁니다.

primaryUpdateMethod: 재시작이냐 switchover냐​

primary를 실제로 교체하는 방식은 primaryUpdateMethod가 정합니다.

  • restart (기본값): primary pod를 그 자리에서 재시작합니다. 재시작이 실패하면 switchover로 넘어갑니다.
  • switchover: 가장 앞선 replica를 새 primary로 승격한 뒤 옛 primary pod를 내립니다.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  primaryUpdateStrategy: unsupervised
  primaryUpdateMethod: switchover
  storage:
    size: 1Gi
경고

switchover를 쓸 때는 이미지 이름과 PostgreSQL 설정 파라미터를 동시에 바꿀 수 없습니다. 둘을 한 번에 바꾸려 하면 안 되고, 순서를 나눠 차례로 적용해야 합니다.

restart와 switchover, 언제 무엇을​

restart는 primary가 재시작되는 동안 짧게 쓰기가 멈추지만 primary가 그대로 유지됩니다. switchover는 primary 역할이 다른 pod로 넘어가므로, 승격이 끝나는 순간 클라이언트가 새 primary로 다시 연결합니다. 둘 다 무중단을 지향하지만 쓰기가 끊기는 짧은 구간은 존재하므로, 애플리케이션은 연결 재시도(retry)를 갖춰 두는 편이 안전합니다.

여러 Cluster가 한 번에 대상이 될 때​

Operator를 업그레이드하면 그 Operator가 관리하는 모든 Cluster의 인스턴스 매니저를 새 버전으로 맞춰야 하므로, 여러 Cluster가 동시에 rolling update 대상이 됩니다. 기본값에서는 모든 Cluster의 pod 교체가 함께 시작되어 노드 I/O가 몰리고, 여러 Cluster의 primary 재시작이 같은 시간대에 겹칩니다.

이 동시성은 Operator 설정(3.3)의 두 값으로 늦춥니다. 단위는 초, 기본값은 둘 다 0입니다.

설정의미
CLUSTERS_ROLLOUT_DELAY한 Cluster의 rollout을 시작한 뒤 다른 Cluster를 시작하기까지 최소 대기. Cluster 간 시차
INSTANCES_ROLLOUT_DELAY한 Cluster 안에서 pod 하나를 교체한 뒤 다음 pod을 교체하기까지 최소 대기. 재시작한 인스턴스가 캐시를 다시 채울 시간

CLUSTERS_ROLLOUT_DELAY를 60으로 두면 Cluster들이 1분 간격으로 직렬화됩니다. 대기는 전체 업그레이드 시간을 늘리는 대신 한 시점에 흔들리는 Cluster 수를 하나로 줄입니다. 멀티 테넌트 클러스터라면 켜 두는 편이 안전합니다.

정리​

rolling update는 replica부터 한 번에 하나씩 교체하고 primary를 마지막에 처리해 중단을 최소화합니다. 이미지·extension·restart 필요 설정·resource 변경·Operator 업그레이드가 이 과정을 촉발합니다.

  • primaryUpdateStrategy: primary 전환을 자동(unsupervised)으로 둘지 수동(supervised)으로 둘지
  • primaryUpdateMethod: primary를 재시작(restart)할지 switchover할지 — switchover 시 이미지와 설정 동시 변경은 금지