PostgreSQL 이중화 환경에서 성능 이슈 해결 하기

이전에 PostgreSQL HA 환경에서 장애가 발생했을 때, 이중화 환경 구성 중 Primary / Primary(P,P) 상태로 전환되며 성능 이슈가 발생한 경험을 공유합니다!

이번 사례는 repmgr 기반 Streaming Replication 환경에서 발생하였으며, 최종적으로 repmgr clone 을 통해 정상적으로 북구했습니다.

 

1️⃣ 문제 상황

운영 중이던 PostgreSQL HA 환경은 아래와 같은 구조였습니다.

● Primary DB

- Read / Write 모두 처리

 

● Standby DB

- Read 전용 처리

 

각각 두개의 DB 는 repmgr 기반 Streaming Replication 구성으로 되어있습니다.

해당 환경은 PostgreSQL HA(High Availability) 구성을 통해 장애 발생 시에도 서비스 가용성을 유지하도록 설계되어 있으며, 복제 및 장애 전환 관리를 repmgr 통해서 사용하고 있었습니다.

 

하지만 이전 장애 발생 이후, 다음과 같은 문제가 확인되었습니다.

 

① Primary DB 가 장애로 인하여 다운

② Standby 가 자동으로 Primary 로 승격

③ 기존 Primary 가 복구되면서 repmgr 관계가 깨짐

④ 결과적으로 Primary / Primary(P,P) 상태 형성

 

즉, 두 노드 모두 Primary 역할을 수행하는 비정상적인 구조가 되었습니다.

 

* HA(High Availability) 는 서버 장애가 발생하더라도 서비스 중단을 최소화하기 위해, 이중화된 시스템을 통해 자동 또는 수동으로 서비스를 지속하는 구성 방식이다.

* repmgr 는 PostgreSQL 환경에서 Primary/Standby 복제 상태를 관리하고, 장애 발생 시 Failover 및 노드 등록·복구를 지원하는 Replication 관리 도구이다.

 

2️⃣ 문제로 인한 영향 (Impact)

이 상태에서 가장 큰 문제는 부하 분산 구조가 완전히 붕괴되었다는 점입니다.

 

● 기존 정상 구조

- Primary : Read + Write

- Standby : Read 전용

- 읽기 트래픽 분산 ▶ 성능 안정

- Primary 장애시 Standby 를 통하여 복구 가능

 

● 장애 이후 비정상 구조

- Primary A: Read + Write

- Primary B(기존 Standby): Read + Write

- Replication 끊김

- Standby 역할 부재

 

 

그 결과:

• 모든 트래픽이 각 Primary에 중복 유입
• 읽기 전용 분리가 되지 않아 불필요한 Write 리소스 사용
• 쿼리 부하 증가
• 장애 재발 가능성 상승 (Split-brain 위험)

 

 

3️⃣ 원인 분석 (Root Cause)

이번 문제의 핵심 원인은 repmgr 관리 하에 있던 복제 관계가 장애 상황에서 정상적으로 복구되지 않은 것입니다.

정리하자면 다음과 같습니다.

1. Primary 장애 발생
2. repmgr에 의해 Standby가 Primary로 승격
3. 기존 Primary 복구
4. 기존 Primary가 자동으로 Standby로 되돌아가지 않음
5. repmgr 메타 정보 불일치
6. 결과적으로 Primary / Primary 상태 유지

📌 repmgr은 자동 failover는 수행하지만,
자동 rejoin(재합류)은 명시적으로 처리하지 않으면 보장되지 않습니다.

 

4️⃣ 해결 방안 (Solution)

이번 케이스에서는 가장 안전하고 확실한 방법을 선택했습니다.

✔️ 해결 전략

• 기존 Primary를 완전히 새로운 Standby로 재구성
• repmgr clone을 사용하여 정합성이 보장된 Standby 재생성

수행 절차 개요

① 기준 Primary 선정

• 현재 정상 서비스 중인 Primary를 기준으로 결정

② 기존 Primary DB 중지

systemctl stop postgresql

 

③ 데이터 디렉토리 정리

rm -rf $PGDATA/*

 

④ repgmr clone 수행

repmgr -h <primary_host> -U repmgr -d repmgr clone

 

⑤ Standby 로 등록

repmgr standby register

 

⑥ PostgreSQL 재기동

systemctl start postgresql

 

⑦ 상태 확인

repmgr cluster show

 

➡️ 결과적으로,

• Primary / Standby 구조 정상화
• Read 트래픽 분산 복구
• Replication 안정화

 

5️⃣ 정리 및 교훈 (Conclusion)

이번 장애 사례는 PostgreSQL HA 환경에서 장애 발생 이후 클러스터 상태 점검과 복구 절차의 중요성을 다시 한 번 확인하는 계기가 되었습니다.

 

repmgr 기반 환경에서는 Primary 장애 시 Standby가 자동으로 승격될 수 있으나,

기존 Primary가 복구되었을 때 자동으로 Standby로 재편입되지 않으면 Primary/Primary(P,P) 상태가 유지될 수 있습니다.

 

또한 P,P 상태에서는 복제 관계가 끊긴 채 각 노드가 독립적으로 동작하게 되며,

기존의 Read/Write 분리 구조가 무너져 불필요한 부하가 발생합니다.

 

이번 대응에서는 repmgr clone을 통해 Standby 노드를 재구성함으로써

복제 정합성을 보장하고 Primary/Standby 구조를 명확히 복구하여 문제를 해결하였습니다!

 

참조

- https://blog.formellow.com/posts/kubernetes-deploy_postgresql-ha/

- https://www.postgresql.org/

- https://www.repmgr.org/