CNPG의 복제 정책과 장애 전환

결론부터

데이터를 얼마나 지킬지와 언제 쓰기를 멈출지를 정하고, primary 전환 뒤 앱이 회복하는지까지 확인한다.

DB에 성공 응답을 받은 쓰기를 지키려면 다른 인스턴스가 충분히 따라왔는지 중요하다. 반대로 복제본을 기다리는 동안 쓰기가 멈출 수 있다. 이 선택을 장애가 난 뒤 즉흥적으로 바꾸지 않는다.

이 장에서 처음 나오는 말3개

switchover

정상인 primary에서 다른 인스턴스로 쓰기 역할을 계획적으로 넘기는 작업.

failover

primary 장애에 대응해 다른 인스턴스를 쓰기 역할로 승격하는 작업.

fencing

옛 primary 등 위험한 인스턴스가 잘못된 쓰기를 계속하지 못하도록 격리하는 조치.

동기 복제에서 무엇을 기다리나

Cluster 예제의 spec 아래에 병합할 설정 발췌다. 세 인스턴스 중 standby 한 대의 동기 응답을 요구한다.

postgresql:
  synchronous:
    method: any
    number: 1
    dataDurability: required

required는 필요한 standby가 없으면 커밋을 기다리게 한다. preferred는 사용 가능한 standby 수에 맞춰 조건을 완화할 수 있어 쓰기 가용성은 높아지지만 장애 시 손실 조건도 바뀐다. 단순히 “동기 복제를 켰다”는 말보다 실제 정책과 synchronous_commit을 함께 확인한다. (CNPG 복제 정책)

상황	이 예제의 기대
standby 둘 중 하나만 사용할 수 있음	남은 한 대가 응답하면 동기 조건 충족 가능
standby를 모두 사용할 수 없음	required 정책 때문에 커밋 대기 가능
모든 DB 볼륨을 함께 잃음	동기 복제만으로 해결 불가, 별도 백업 복구 필요

복제 정책과 안전한 승격 후보 선정은 연결되어 있지만 동일하지 않다. quorum 기반 failover 같은 추가 정책과 네트워크 분할 조건은 공식 문서를 확인한다. replica 수만으로 모든 장애에서 무손실이라고 단정하지 않는다. (자동 failover)

먼저 계획 전환으로 경로 확인하기

전제는 준비된 실습 Cluster, 정상 replica, 검증된 백업이다. 다음 첫 명령으로 현재 primary와 후보를 확인한다. study-pg-2는 실제로 정상 standby일 때만 쓰는 예시 이름이다.

kubectl cnpg status -n pg-study study-pg
kubectl cnpg promote -n pg-study study-pg study-pg-2
kubectl cnpg status -n pg-study study-pg
kubectl get endpointslices -n pg-study \
  -l kubernetes.io/service-name=study-pg-rw

primary가 후보로 바뀌고 -rw의 준비된 대상도 새 primary로 바뀌는지 확인한다. 상태가 안정된 뒤 원래 인스턴스도 건강한 standby라면 같은 promote 명령의 대상만 바꿔 다시 계획 전환할 수 있다. Pod 번호가 쓰기 역할을 영구히 결정하는 것은 아니다. (kubectl 플러그인)

앱의 회복은 따로 관찰한다

운영 전환 검증에서는 실제 앱 role과 study-pg-rw 또는 앱 풀러를 사용하는 테스트 클라이언트를 준비한다. 단조 증가하는 요청 ID를 기록하고 성공·실패·재시도를 구분한다. 관리자 kubectl cnpg psql만 성공하는 것으로 네트워크·Secret·연결 풀까지 검증됐다고 보지 않는다.

관찰	이유
마지막 성공 쓰기와 전환 후 조회	앱이 성공으로 기록한 데이터가 남았는지 확인
첫 실패부터 재연결·쓰기 성공까지의 시간	DB 승격 시간과 사용자 체감 복구 시간 구분
실패 중 요청의 재처리	COMMIT 응답을 못 받은 요청의 중복·누락 확인
옛 primary의 역할과 상태	복귀한 인스턴스가 별도 writer로 남지 않는지 확인

계획 전환이 장애 실험을 대신하지는 않는다

Pod 삭제, 노드 정지, 네트워크 분할, 디스크 손실은 서로 다른 실패다. 한 종류의 성공으로 모두 검증했다고 하지 않는다. 실제 장애 실험은 필요한 격리·복구 절차와 측정 기준을 정한 별도 실습에서 진행한다. 이 문서의 promote 예제는 정상 상태에서의 switchover다.

이해 확인: -rw 주소가 같으면 앱에서 오류 처리를 생략할 수 있을까? 아니다. 기존 연결이 끊기고 트랜잭션 결과가 불확실할 수 있으므로 실패 처리가 필요하다.