PostgreSQL HA (2) - HA 설정 및 Fail-over 테스트

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

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

---

안녕하세요, 여행자 K 입니다.
이전 글에서 PostgreSQL 고가용성(HA)의 개념과 작동 방식에 대해 알아보았습니다. 이번 글에서는 실제로 PostgreSQL 환경에서 Fail-over를 설정하는 방법을 단계별로 상세히 안내해 드리겠습니다. Fail-over는 Primary 서버에 장애가 발생했을 때 Standby 서버가 자동으로 Primary 역할을 승계하여 서비스 중단을 최소화하는 핵심 기술입니다. 체계적인 설정을 통해 안정적인 고가용성 환경을 구축해보겠습니다.

---

Fail-over란?

Fail-over는 주 서버(Primary)에 장애가 발생했을 때, 대기 서버(Standby)가 자동 또는 수동으로 주 서버의 역할을 인수받아 서비스 연속성을 보장하는 메커니즘입니다. PostgreSQL에서는 스트리밍 복제(Streaming Replication)를 기반으로 Standby 서버가 Primary 서버의 데이터를 실시간으로 동기화하며, 장애 발생 시 Standby 서버를 Primary로 승격(Promote)시켜 운영을 지속합니다.

주요 특징

• 자동 장애 탐지: Primary 서버의 장애를 신속하게 감지합니다.
• 빠른 역할 전환: Standby 서버가 Primary로 승격되어 읽기/쓰기 작업을 처리합니다.
• 최소한의 데이터 손실: 스트리밍 복제를 통해 데이터 일관성을 최대한 유지합니다.
• 서비스 연속성: 사용자는 장애 발생을 거의 인지하지 못하고 서비스를 계속 이용할 수 있습니다.

Fail-over 설정 전 준비사항

Fail-over 설정을 시작하기 전에 다음 사항들이 준비되어 있어야 합니다:

1. 서버 구성

• PostgreSQL#1 (Primary 서버)
• PostgreSQL#2 (Standby 서버)
• 두 서버 간 네트워크 통신 가능

2. 기본 설정 완료 상태

• PostgreSQL 설치 완료
• 관리자 계정 설정 완료
• 외부 접속 허용 설정 완료
• 복제 대상 DB 생성 완료 (필요시)

Fail-over 설정 단계

아래의 단계를 통해 Fail-over를 위한 복제 설정을 진행합니다.

 

1. Primary 서버(PostgreSQL#1) 복제 설정

Primary 서버에서 스트리밍 복제를 위한 설정을 진행합니다.

1-1. postgresql.conf 파일 수정

PostgreSQL#2 서버와의 복제 연결을 위해 다음 파라미터를 설정합니다.

vi /var/lib/pgsql/15/data/postgresql.conf

설정할 내용:

# 네트워크 설정
listen_addresses = '*'

# WAL(Write-Ahead Logging) 설정
wal_level = replica

# 최대 복제 연결 수
max_wal_senders = 10

# WAL 보관 크기 (복제 지연 시 대비)
wal_keep_size = 512MB

# Hot Standby 모드 활성화
hot_standby = on

설정 항목 설명:

• listen_addresses: 모든 IP에서 접속 허용
• wal_level: 복제를 위한 WAL 로그 레벨 설정
• max_wal_senders: 동시에 연결 가능한 Standby 서버 수
• wal_keep_size: 네트워크 지연 시 WAL 파일을 보관할 크기
• hot_standby: Standby 서버에서 읽기 전용 쿼리 허용

 

1-2. pg_hba.conf 파일 수정

복제를 위한 인증 설정을 추가합니다.

vi /var/lib/pgsql/15/data/pg_hba.conf

추가할 내용:

# Replication 접속 허용
local   replication     postgres                        trust
host    replication     postgres    127.0.0.1/32        trust
host    replication     postgres    [PostgreSQL2 IP대역]/24    trust

설정 내용 설명:

• replication: 복제 연결을 위한 특수 데이터베이스
• trust: 패스워드 없이 접속 허용 (보안이 필요한 경우 md5 또는 scram-sha-256 사용 권장)
• IP 대역은 실제 환경에 맞게 수정

 

1-3. PostgreSQL 서비스 재시작

설정을 적용하기 위해 서비스를 재시작합니다.

systemctl restart postgresql-15.service

서비스 상태 확인:

systemctl status postgresql-15.service

2. Standby 서버(PostgreSQL#2) 복제 설정

Standby 서버에서 Primary 서버의 데이터를 복제하고 Standby 모드로 전환합니다.

2-1. PostgreSQL 서비스 중지

Primary 서버의 데이터를 복제하기 전에 Standby 서버의 서비스를 중지합니다.

systemctl stop postgresql-15.service

 

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

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

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

주의사항: 이 작업은 Standby 서버의 모든 기존 데이터를 삭제합니다. 백업이 필요한 경우 사전에 백업을 수행하세요.

 

2-3. Primary 서버에서 베이스 백업 수행

Primary 서버의 데이터를 복제하고 자동으로 Standby 모드로 설정합니다.

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

명령어 옵션 설명:

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

 

2-4. PostgreSQL 서비스 시작

Standby 역할 수행을 위해 서비스를 시작합니다.

systemctl start postgresql-15.service

서비스 상태 확인:

systemctl status postgresql-15.service

3. 복제 상태 확인

각 서버의 현재 상태와 복제 연결을 확인합니다.

3-1. 서버 역할 확인

각 서버에서 현재 역할(Primary/Standby)을 확인합니다.

PostgreSQL#1에서 실행:

SELECT pg_is_in_recovery();

• f (false): Primary 역할 상태

 

PostgreSQL#2에서 실행:

SELECT pg_is_in_recovery();

• t (true): Standby 역할 상태

 

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

Primary 서버에서 복제 연결 상태를 확인합니다.

PostgreSQL#1에서 실행:

SELECT client_addr, state, sync_state FROM pg_stat_replication;

결과 설명:

• state: streaming (정상 복제 중)
• sync_state: async (비동기 복제) 또는 sync (동기 복제)

 

3-3. 복제 지연 확인

Primary 서버에서 복제 지연 상태를 확인합니다.

PostgreSQL#1에서 실행:

SELECT client_addr, application_name, state, pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replication_lag_bytes FROM pg_stat_replication;

결과 해석:

replication_lag_bytes가 0에 가까울수록 복제 지연이 적습니다.

4. Standby 읽기 전용 모드 검증 (선택사항)

Fail-over 테스트 전에 Standby 서버가 올바르게 읽기 전용 모드로 동작하는지 확인합니다.

PostgreSQL#2에서 실행:

CREATE TABLE test_readonly (id SERIAL);

Standby 상태에서는 데이터 조회만 가능하며 삽입, 수정, 삭제가 불가능합니다. 이 에러가 출력되면 정상적으로 Standby 모드로 동작하고 있는 것입니다.

Fail-over 테스트

HA 설정이 완료되었으면 실제 Fail-over를 테스트해봅니다.

 

1. Primary 서버 장애 시뮬레이션

PostgreSQL#1 서버의 PostgreSQL 서비스 장애를 가정하여 서비스를 중지합니다.

PostgreSQL#1에서 실행:

systemctl stop postgresql-15.service

2. Standby 서버를 Primary로 승격

PostgreSQL#2 서버의 역할 승격을 진행합니다.

2-1. PostgreSQL 서비스 중지

Standby 서버의 서비스를 중지합니다.

PostgreSQL#2에서 실행:

systemctl stop postgresql-15.service

2-2. standby.signal 파일 삭제

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

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

 

2-3. PostgreSQL 서비스 재시작

중지된 서비스를 재시작합니다.

systemctl start postgresql-15.service

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

3. 승격 확인

PostgreSQL#2 서버의 역할 승격을 확인합니다.

3-1. 서버 역할 확인

PostgreSQL#2 서버의 현재 역할을 확인합니다.

PostgreSQL#2에서 실행:

SELECT pg_is_in_recovery();

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

 

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

새로운 Primary 서버(PostgreSQL#2)에서 데이터를 쓸 수 있는지 확인합니다.

PostgreSQL#2에서 실행:

-- 테스트 테이블 생성
CREATE TABLE failover_test ( id SERIAL PRIMARY KEY, test_time TIMESTAMP DEFAULT NOW() );

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

-- 확인
SELECT * FROM failover_test;

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

Fail-over 시 주의사항

1. 복제 연결 끊김

• Primary 서버가 중단되면 Standby 서버와의 복제 연결이 끊어집니다.
• Standby를 Primary로 승격한 후에는 이전 Primary 서버를 재시작해도 자동으로 복제가 재개되지 않습니다.

2. Split-brain 방지

• 이전 Primary 서버가 복구되어 동시에 두 개의 Primary가 존재하는 상황을 방지해야 합니다.
• 이전 Primary는 반드시 Standby로 재구성한 후 재시작해야 합니다.

3. 데이터 손실 가능성

• 비동기 복제 모드에서는 장애 시점에 복제되지 않은 일부 트랜잭션이 손실될 수 있습니다.
• 데이터 손실을 최소화하려면 동기 복제(synchronous_commit = on) 사용을 고려하세요.

---

오늘은 PostgreSQL 환경에서 Fail-over를 설정하는 방법에 대해 상세히 알아보았습니다. 스트리밍 복제를 통한 데이터 동기화와 Standby 서버의 승격 과정을 통해 서비스 연속성을 보장할 수 있습니다.

다음 글에서는 Fail-back 설정 방법에 대해 안내해 드리겠습니다. Fail-back은 장애가 복구된 원래 Primary 서버를 다시 Primary 역할로 되돌리는 과정으로, 안정적인 HA 운영을 위해 매우 중요합니다.

고가용성 환경 구축은 초기 설정이 다소 복잡할 수 있지만, 한 번 제대로 구축해두면 안정적이고 신뢰할 수 있는 데이터베이스 서비스를 제공할 수 있습니다.

읽어주셔서 감사합니다.

---