PostgreSQL HA (3) - Fail-back 설정

2026.02.16 - [DB/PostgreSQL] - PostgreSQL HA (1) - HA의 개념과 역할

2026.02.23 - [DB/PostgreSQL] - PostgreSQL HA (2) - HA 설정 및 Fail-over 테스트

이전 글에서 이어서 진행 됩니다.

---

안녕하세요, 여행자 K 입니다.

이전 글에서 Fail-over 설정 방법을 알아보았습니다. 이번 글에서는 Fail-back 설정 방법을 단계별로 상세히 안내해 드리겠습니다. Fail-back은 장애가 복구된 원래 Primary 서버를 다시 Primary 역할로 되돌려 정상적인 HA 구성으로 복원하는 과정입니다. 안정적인 고가용성 환경 운영을 위해 필수적인 절차입니다.

---

Fail-back이란?

Fail-back은 Fail-over 이후 장애가 복구된 원래 Primary 서버(PostgreSQL#1)를 다시 Primary 역할로 전환하고, 현재 Primary로 동작 중인 서버(PostgreSQL#2)를 Standby로 되돌리는 작업입니다. 이를 통해 원래의 HA 구성으로 복원하여 시스템을 정상 상태로 되돌립니다.

주요 특징

• 시스템 정상화: 원래의 Primary/Standby 구조로 복원합니다.
• 역할 재전환: PostgreSQL#1을 Primary로, PostgreSQL#2를 Standby로 재설정합니다.
• 데이터 동기화: 복구된 서버가 현재 Primary의 최신 데이터를 동기화합니다.
• 운영 연속성: Fail-back 과정 중에도 서비스 중단을 최소화합니다.

Fail-back 설정 전 상황 확인

Fail-back을 시작하기 전에 현재 상태를 확인해야 합니다:

1. 현재 시스템 상태 (Fail-over 완료 후)

• PostgreSQL#1: 중지 상태 (장애 발생했던 서버)
• PostgreSQL#2: Primary 역할로 동작 중 (Fail-over로 승격된 서버)
• 애플리케이션은 PostgreSQL#2에 연결되어 서비스 중

2. Fail-back 목표 상태

• PostgreSQL#1: Primary 역할 (원래 역할로 복귀)
• PostgreSQL#2: Standby 역할 (원래 역할로 복귀)
• 정상적인 스트리밍 복제 재개

Fail-back 설정 단계

아래의 단계를 통해 Fail-back을 진행합니다.

 

1. PostgreSQL#1 서버를 Standby로 재구성

장애가 복구된 PostgreSQL#1을 Standby 서버로 설정하여 현재 Primary(PostgreSQL#2)의 데이터를 복제받습니다.

1-1. PostgreSQL#1 서비스 상태 확인

현재 PostgreSQL#1이 중지되어 있는지 확인합니다.

PostgreSQL#1에서 실행:

systemctl status postgresql-15.service

서비스가 실행 중이라면 중지합니다:

systemctl stop postgresql-15.service

 

1-2. 기존 데이터 디렉토리 삭제

PostgreSQL#2의 최신 데이터를 복제하기 위해 PostgreSQL#1의 기존 데이터를 삭제합니다.

PostgreSQL#1에서 실행:

rm -rf /var/lib/pgsql/15/data

주의사항: 이 작업은 PostgreSQL#1의 모든 데이터를 삭제합니다. 현재 Primary인 PostgreSQL#2에 최신 데이터가 있으므로 문제없지만, 실행 전 반드시 확인하세요.

 

1-3. Primary 서버(PostgreSQL#2)에서 베이스 백업 수행

현재 Primary인 PostgreSQL#2의 데이터를 PostgreSQL#1로 복제하고 Standby 모드로 설정합니다.

PostgreSQL#1에서 실행:

pg_basebackup -h [PostgreSQL2 서버 IP] -U postgres -D /var/lib/pgsql/15/data -P -R

명령어 옵션 설명:

• -h: 현재 Primary 서버(PostgreSQL#2)의 IP 주소
• -U: 접속할 사용자 이름 (postgres)
• -D: 데이터를 저장할 디렉토리
• -P: 진행 상황 표시
• -R: standby.signal 파일 자동 생성 및 복제 설정 추가

 

1-4. PostgreSQL#1 서비스 시작

PostgreSQL#1을 Standby 역할로 시작합니다.

PostgreSQL#1에서 실행:

systemctl start postgresql-15.service

서비스 상태 확인:

systemctl status postgresql-15.service

2. 복제 상태 확인

PostgreSQL#1이 Standby로 정상 동작하고, PostgreSQL#2가 Primary로서 복제를 제공하는지 확인합니다.

2-1. 서버 역할 확인

PostgreSQL#1에서 실행:

SELECT pg_is_in_recovery();

• t (true): Standby 역할 상태

 

PostgreSQL#2에서 실행:

SELECT pg_is_in_recovery();

• f (false): Primary 역할 상태

 

2-2. 복제 연결 상태 확인

PostgreSQL#2에서 PostgreSQL#1으로의 복제 연결이 정상적으로 동작하는지 확인합니다.

PostgreSQL#2에서 실행:

SELECT client_addr, state, sync_state FROM pg_stat_replication;

결과 설명:

• client_addr: PostgreSQL#1의 IP 주소
• state: streaming (정상 복제 중)
• sync_state: async (비동기 복제)

3. Primary 역할 전환 (PostgreSQL#2 → PostgreSQL#1)

현재 Primary인 PostgreSQL#2를 Standby로 전환하고, PostgreSQL#1을 Primary로 승격하여 원래 구성으로 복원합니다.

3-1. PostgreSQL#2를 Standby로 전환

3-1-1. PostgreSQL#2 서비스 중지

현재 Primary인 PostgreSQL#2의 서비스를 중지합니다.

PostgreSQL#2에서 실행:

systemctl stop postgresql-15.service

 

3-1-2. PostgreSQL#2 데이터 디렉토리 삭제

PostgreSQL#1의 데이터를 복제받기 위해 기존 데이터를 삭제합니다.

PostgreSQL#2에서 실행:

rm -rf /var/lib/pgsql/15/data

주의사항: 이 시점에 PostgreSQL#1이 Standby로 동작 중이므로 최신 데이터가 동기화되어 있습니다. 하지만 애플리케이션 연결이 끊기므로 서비스 중단이 발생합니다.

 

3-2. PostgreSQL#1을 Primary로 승격

3-2-1. PostgreSQL#1 서비스 중지

Standby에서 Primary로 전환하기 위해 서비스를 중지합니다.

PostgreSQL#1에서 실행:

systemctl stop postgresql-15.service

 

3-2-2. standby.signal 파일 삭제

Standby 모드를 해제하기 위해 standby.signal 파일을 삭제합니다.

PostgreSQL#1에서 실행:

rm /var/lib/pgsql/15/data/standby.signal

 

3-2-3. PostgreSQL#1 서비스 재시작

서비스를 재시작하여 Primary 모드로 전환합니다.

PostgreSQL#1에서 실행:

systemctl start postgresql-15.service

PostgreSQL은 재시작 시 standby.signal 파일이 없으면 자동으로 Primary 모드로 전환됩니다.

 

3-2-4. PostgreSQL#1 역할 확인

PostgreSQL#1에서 실행:

SELECT pg_is_in_recovery();

• f (false): Primary 역할로 승격 완료

3-3. PostgreSQL#2를 Standby로 재구성

3-3-1. PostgreSQL#1에서 베이스 백업 수행

새로운 Primary인 PostgreSQL#1의 데이터를 PostgreSQL#2로 복제합니다.

PostgreSQL#2에서 실행:

pg_basebackup -h [PostgreSQL1 서버 IP] -U postgres -D /var/lib/pgsql/15/data -P -R

 

3-3-2. PostgreSQL#2 서비스 시작

PostgreSQL#2를 Standby 역할로 시작합니다.

PostgreSQL#2에서 실행:

systemctl start postgresql-15.service

서비스 상태 확인:

systemctl statuspostgresql-15.service

4. Fail-back 완료 확인

원래의 HA 구성으로 정상 복원되었는지 최종 확인합니다.

4-1. 서버 역할 최종 확인

PostgreSQL#1에서 실행:

SELECT pg_is_in_recovery();

• f (false): Primary 역할 (원래 역할로 복귀)

 

PostgreSQL#2에서 실행:

SELECT pg_is_in_recovery();

• t (true): Standby 역할 (원래 역할로 복귀)

 

4-2. 복제 연결 상태 확인

PostgreSQL#1에서 실행:

SELECT client_addr, state, sync_state FROM pg_stat_replication;

결과 설명:

• client_addr: PostgreSQL#2의 IP 주소
• state: streaming (정상 복제 중)
• 원래의 Primary → Standby 복제 구조로 복원 완료

 

4-3. 데이터 쓰기 테스트

PostgreSQL#1에서 데이터를 정상적으로 쓸 수 있는지 확인합니다.

PostgreSQL#1에서 실행:

-- 데이터 삽입
INSERT INTO failover_test VALUES (DEFAULT);

-- 확인
SELECT * FROM failover_test;

정상적으로 데이터가 삽입되면 Fail-back이 성공적으로 완료된 것입니다.

Fail-back 시 주의사항

1. 서비스 중단 최소화

• 3단계에서 Primary 전환 시 짧은 시간 동안 서비스 중단이 발생합니다.
• 점검 시간대에 작업하거나 사용자에게 사전 공지가 필요합니다.

2. 데이터 동기화 확인

• 1단계에서 PostgreSQL#1이 Standby로 동작할 때 복제 지연이 없는지 확인해야 합니다.
• 복제 지연이 있는 상태에서 3단계를 진행하면 데이터 손실이 발생할 수 있습니다.

3. 작업 순서 준수

• 반드시 1단계 → 2단계 → 3단계 → 4단계 순서로 진행해야 합니다.
• 순서를 바꾸면 데이터 불일치나 복제 실패가 발생할 수 있습니다.

4. 롤백 계획 준비

• Fail-back 중 문제가 발생하면 PostgreSQL#2를 다시 Primary로 전환할 수 있도록 준비합니다.
• 각 단계별로 상태를 확인하고 문제 발생 시 즉시 중단합니다.

5. 백업 수행

• Fail-back 작업 전 PostgreSQL#2(현재 Primary)의 전체 백업을 권장합니다.
• 예상치 못한 문제 발생 시 백업에서 복구할 수 있습니다.

---

PostgreSQL 환경에서 Fail-back을 설정하는 방법에 대해 상세히 알아보았습니다. Fail-over 이후 원래의 HA 구성으로 시스템을 복원하는 과정을 통해 안정적이고 체계적인 고가용성 운영이 가능합니다.

지금까지 총 3편의 시리즈를 통해 PostgreSQL HA의 개념부터 Fail-over, Fail-back 설정까지 모든 과정을 다루었습니다. 이러한 고가용성 환경 구축은 초기 설정이 다소 복잡하지만, 한 번 제대로 구축하고 운영 절차를 숙지해두면 장애 상황에서도 안정적인 서비스 연속성을 보장할 수 있습니다.

실무에서는 자동 Fail-over/Fail-back 도구(Patroni, repmgr 등)를 활용하여 관리자의 개입을 최소화하는 것도 고려해볼 만합니다. 하지만 이러한 자동화 도구를 사용하더라도 수동 절차를 정확히 이해하고 있어야 예상치 못한 상황에 대처할 수 있습니다.

읽어주셔서 감사합니다.

---