2.4 장애 모델
CloudNativePG의 장애 처리는 특별한 마법이 아니라 Kubernetes의 표준 동작 위에 self-healing을 더한 것입니다. 대부분의 장애는 조정 루프가 "원하는 상태와 현재 상태의 차이"를 감지해 자동으로 메웁니다. 여기서는 어떤 장애가 자동으로 복구되고, 어떤 경우에 사람이 개입해야 하는지를 구분해 정리합니다.
자동 복구 (self-healing)
primary Pod 장애
primary가 죽으면 failover가 시작됩니다.
- Operator가 복제 지연이 가장 적은 최신 standby를 승격 후보로 고릅니다
- 그 standby를 새 primary로 승격합니다
-rw서비스를 새 primary로 돌리고, 죽은 Pod를-r·-rw에서 뺍니다- 남은 replica들은 새 primary를 바라보고 복제를 잇습니다
- 옛 primary는 PVC가 살아 있으면
pg_rewind로 다시 합류하고, PVC가 없으면 새 primary의 백업에서 재생성됩니다
replica Pod 장애
replica가 죽으면 더 단순합니다.
- 해당 Pod를
-r·-ro서비스에서 뺍니다 - 기존 PVC가 있으면 그 PVC로 Pod를 재시작합니다
- PVC를 못 쓰면 현재 primary의 백업에서 새로 만듭니다
- 준비가 끝나면 다시
-r·-ro서비스에 넣습니다
replica 장애는 쓰기(primary)에 영향을 주지 않으므로 서비스 연속성 관점에서 영향이 작습니다.
PVC 장애, 노드 장애, 스토리지 이슈 같은 시나리오는 CloudNativePG 고유 로직이라기보다 Kubernetes 표준 동작을 따릅니다. 노드가 offline이 되면 그 위 Pod는 결국 스케줄에서 빠지고, primary였다면 위의 failover 절차가 돕니다. 세부 동작은 Kubernetes 문서(node eviction, PVC 재바인딩 등)를 함께 참고합니다.
자동으로 처리하지 않는 것
self-healing이 오히려 해로운 상황도 있습니다. 대표적인 것이 디스크 풀입니다.
인스턴스 매니저는 스토리지가 고갈되면 failover를 트리거하지 않습니다. 원인이 데이터 증가나 WAL 적체라면 다른 Pod로 옮겨도 같은 벽에 부딪히기 때문입니다. 이때는 사람이 PVC 크기를 늘리고 Cluster 리소스를 맞춰 갱신해야 정상으로 돌아옵니다.
수동 개입: 조정 루프 멈추기
긴급 상황에서 Operator의 자동 조정이 오히려 방해가 될 때가 있습니다. 예를 들어 수동으로 데이터를 손보는 중인데 Operator가 자꾸 원래 상태로 되돌린다면 곤란합니다. 이때는 조정 루프를 잠시 끕니다.
# 특정 Cluster의 조정 루프를 일시 중지
kubectl annotate cluster pg cnpg.io/reconciliationLoop=disabled
# 작업이 끝나면 반드시 원복
kubectl annotate cluster pg cnpg.io/reconciliationLoop-
이 annotation은 Cluster·Backup 리소스에 적용됩니다.
reconciliationLoop=disabled는 Operator의 눈을 가리는 것입니다. 이 상태에서는 자동 failover·self-healing이 모두 멈춥니다. 긴급 작업에만 쓰고, 끝나는 즉시 annotation을 제거해 자동 운영을 되살려야 합니다. 켜 둔 채로 방치하면 진짜 장애가 나도 아무도 복구하지 않습니다.
정리
대부분의 장애는 조정 루프가 원하는 상태와 현재 상태의 차이를 메우며 자동으로 복구됩니다. primary가 죽으면 최신 standby가 승격되고 -rw 서비스가 갱신되며 옛 primary는 pg_rewind나 재생성으로 돌아옵니다. replica 장애는 서비스에서 잠깐 빠졌다 PVC 재사용 또는 재생성으로 복귀할 뿐 쓰기에는 영향을 주지 않습니다. 반면 디스크 풀처럼 자동화가 오히려 해로운 상황에서는 failover 대신 사람이 PVC를 늘려야 하고, 긴급 수동 작업 중에는 cnpg.io/reconciliationLoop=disabled로 조정을 멈추되 끝나면 즉시 원복합니다.