PostgreSQL: DBMS 이중화 구성 방법

※ Setting up PostgreSQL DBMS Replication Configuration.
※ Version: Linux 8.10 (Rocky), PostgreSQL 16.4.

이전 포스팅에서 우리는 주요 파라미터 설정을 하고 PostgreSQL 싱글 서버 구성을 완료했습니다.
 
이번 글에서는 DBMS(Database Management System) 이중화 구성을 실습해 보겠습니다.

본격적인 실습에 앞서 DBMS 이중화란 무엇이며 이를 구성하는 이유는 무엇인지 살펴보겠습니다.

---

DBMS 이중화?

• DBMS 이중화는 데이터베이스 관리 시스템의 가용성(Availability)과 안정성(Reliability)을 높이기 위한 기술입니다.
• 하나의 시스템에 장애가 발생해도 다른 시스템이 이를 이어받아 서비스 중단을 최소화하는 구성을 의미합니다.
 
DBMS 이중화는 HA(High Availability)와 Failover 시스템 구성에 활용되며, 아래와 같은 주요 목적을 가집니다.
 

DBMS 이중화를 구성하는 이유

1. 서비스 가용성 보장
• 단일 장애점(Single Point of Failure, SPOF)을 제거하여 장애 상황에서도 서비스가 지속되도록 보장합니다.

2. 장애 복구
• 하드웨어, 네트워크, 소프트웨어 문제로 인한 장애 발생 시 다른 시스템이 즉시 서비스를 이어받아 중단 시간을 최소화합니다.

3. 데이터 안전성 확보
• 실시간 데이터 복제 또는 동기화를 통해 데이터 손실을 방지하고 데이터를 안전하게 유지합니다.

4. 성능 향상
• 읽기/쓰기 작업을 여러 시스템으로 분산 처리하여 부하를 줄이고, 특히 읽기 요청이 많은 환경에서는 Read Replica를 활용해 성능을 극대화할 수 있습니다.

5.유지보수 및 업데이트 용이성
• 이중화된 환경에서는 한 시스템에서 업데이트나 유지보수를 진행하는 동안 다른 시스템이 서비스를 지속적으로 제공할 수 있습니다.
 
이제 DBMS 이중화를 구성하는 방식과 구성 시 고려 사항에 대해 알아보겠습니다.
 

DBMS 이중화 방식

DBMS 이중화에는 Active-Standby와 Active-Active 구성이 있습니다.

1. Active-Standby 구성
• 구조:
→ 주로 Active 노드가 서비스 요청을 처리합니다(쓰기 작업은 Active-Only).
→ Standby 노드는 대기 상태로 있다가 Active 노드 장애 시에만 서비스 역할 수행합니다.
→ DBMS 설정에 따라 Standby 노드를 Read-Only 상태로 활용할 수 있습니다.

• 방식:
▫ 동기식 복제(Synchronous):
→ 장점: 높은 데이터 일관성을 보장합니다.
→ 단점: 네트워크 지연과 동기화로 인해 성능 저하가 발생할 수 있습니다.

▫ 비동기식 복제(Asynchronous):
→ 장점: 성능에 중점을 둔 방식입니다.
→ 단점: 장애 발생 시 마지막 복제 시점 이후의 데이터가 유실될 가능성이 있습니다.

2. Active-Active 구성
• 구조:
두 시스템이 동시에 활성화되어 작업을 병렬 처리합니다.
주요 목적은 부하 분산(Load Balancing)과 높은 가용성 제공입니다.

• 특징:
→ 동기화 문제 해결이 필요하며, 이를 위해 데이터 충돌 방지 및 실시간 동기화 기술이 필요합니다.
(Locking Mechanisms, Conflict Resolution 등)
→ 포스팅 시점 기준으로 Oracle DBMS만 온전한 Active-Active 구성 가능합니다.
 

이중화를 구성할 때 고려할 점

1. 이중화 방식 선택
• Active-Standby:
→ 동기식 복제(Synchronous): 데이터 일관성 중요할 때 적합합니다.
→ 비동기식 복제(Asynchronous): 성능을 우선시할 때 적합하지만, 장애 발생 시 일부 데이터 유실 가능성이 존재합니다.

• Active- Active:
→ 동시 활성화 및 쓰기 작업 분산 필요 시 선택합니다.
→ 동기화 문제 해결을 위한 추가적인 기술적 조치(Oracel RAC) 필요합니다.

2. 장애 전환(Failover) 시간
• 장애 발생 시 서비스 전환이 얼마나 빠르게 이루어지는지가 중요합니다.
• Failover를 빠르게 처리할 수 있도록 구성이 필요합니다.

3. 데이터 일관성 및 정합성
• 다중 시스템 간 데이터 동기화를 위한 기법 사용:
→ 동기식 복제(Synchronous)
→ Locking Mechanisms, Conflict Resolution Mechanisms(Active-Active 환경에서 충돌 방지)

4. 운영 비용 및 관리 복잡성
• 이중화 시스템은 추가적인 하드웨어, 네트워크 장비, 스토리지 도입으로 운영 비용이 증가하며, 장애 복구, 데이터 동기화 등의 관리 복잡성 또한 높아질 수 있습니다.
→ 효과적으로 관리하기 위해 전문 인력과 모니터링 도구의 도입이 권장됩니다.
 
DBMS 이중화란 무엇이고, 어떤 목적으로 사용하는지, 구성 방식과 고려해야 할 점을 살펴보았습니다.
 
이제 PostgreSQL의 Physical Streaming Replication 기능을 활용해 DBMS 이중화 방법을 실습해 보겠습니다.
 
이번 실습에는 동일한 버전의 PostgreSQL이 설치된 두 대의 싱글 서버가 필요합니다.

---

우리가 구성할 아키텍처입니다.

[그림 1] 이중화 아키텍처

---

1. 사전 준비

• 두 서버에 설치된 PostgreSQL 버전은 반드시 동일해야 합니다.
• 두 서버 간 PostgreSQL 기본 포트(5432)에 대해 TCP 통신이 허용되어야 합니다.

---

2. Active(Primary) 서버 설정

▸ postgresql.conf 수정

# replication settings
wal_level = replica
hot_standby = on
max_wal_senders = 10 # WAL Sender 프로세스의 최대 개수를 설정하는 파라미터
max_replication_slots = 10 # Replication Slot의 최대 개수를 설정하는 파라미터
max_slot_wal_keep_size = 10GB # Replication Slot의 WAL 보관 상한선

 
▸ pg_hba.conf 수정

# replication
host    replication     replicator      <primary_IP_address>/32      trust
host    replication     replicator      <standby_IP_address>/32      trust

# for rewind
host    postgres        replicator      <primary_IP_address>/32      trust
host    postgres        replicator      <standby_IP_address>/32      trust

 
▸ 파라미터 적용을 위해 아래 명령어로 재기동

pg_ctl restart

 
▸ Replication Role 생성

CREATE ROLE replicator WITH REPLICATION PASSWORD 'replicator_password' LOGIN;

---

3.1 Replication Slot 미사용 방식 (기본 Streaming Replication)

▸ Standby 서버 데이터 영역 정리

rm -rf $PGDATA/*

 
▸ Primary 서버 데이터 복제
→ 베이스백업을 활용하여 초기 데이터 복제

pg_basebackup -h <primary_IP_address> -U replicator -D /data -Fp -Xs -P

 
▸ Standby 서버에 standby.signal 파일 생성

touch $PGDATA/standby.signal

PostgreSQL은 standby.signal 파일이 존재하면 서버를 standby 모드로 기동합니다. (구 버전은 recovery.conf)

▸ Standby 서버 postgresql.conf 설정

# connection info
primary_conninfo = 'host=<primary_IP_address> port=5432 user=replicator password=replicator_password application_name=node02_standby'

 
▸ Standby 서버 시작

pg_ctl start

---

3.2 Replication Slot 사용 방식

Replication slot을 사용하면 standby가 잠시 끊기더라도 필요한 WAL이 primary에서 제거되지 않도록 보장할 수 있습니다.

wal_keep_size 같은 단순 WAL 보존보다 특정 standby 기준으로 필요한 WAL을 더 정확히 유지하는 방식입니다.
다만 standby가 장시간 장애 상태면 primary의 pg_wal이 계속 증가할 수 있으므로 모니터링이 필수입니다.

 

▸ Primary 서버에서 Physical Replication Slot 생성

SELECT * FROM pg_create_physical_replication_slot('node02_slot');

 

▸ Primary 서버 데이터 복제

→  Base Backup 수행 시 slot 사용

pg_basebackup -h <primary_IP_address> -U replicator -D $PGDATA -Fp -Xs -P -R -S node02_slot

• -S node02_slot : base backup 중 WAL streaming에 사용할 replication slot 지정
• -R : standby.signal 생성 및 primary_conninfo 등의 recovery 관련 설정 자동 반영

PostgreSQL 공식 문서에 따르면 slot을 사용해 standby를 만들 경우 base backup 시 사용한 slot 이름과 standby의 primary_slot_name을 동일하게 맞추는 것이 권장됩니다. 그래야 base backup 종료 후 standby가 실제 streaming을 시작하기 전 사이에 필요한 WAL이 primary에서 제거되지 않습니다.

 

▸ Standby 서버 postgresql.conf 설정

primary_conninfo = 'host=<primary_IP_address> port=5432 user=replicator password=replicator_password application_name=node02_standby'
primary_slot_name = 'node02_slot' # standby가 primary의 어떤 replication slot을 사용할지 지정

 

▸ Standby 서버 시작

pg_ctl start

---

4. 복제 상태 확인

▸ Primary 서버에서 확인

psql
SELECT * FROM pg_stat_replication;

 
▸ Primary 서버에서 테이블 생성

CREATE TABLE test_table (i int);

 
▸ Standby 서버에서 생성된 테이블 확인

psql
\dt

[그림 2] 복제 상태 확인 예시

 
 
▸ OS 명령어로 프로세스 상태 확인

ps -ef | grep postgres

[그림 3] OS 명령어로 프로세스 상태 확인 예시

---

이번 포스팅에서 우리는 PostgreSQL 이중화 구성까지 완료하였습니다.
 
다음 포스팅에서는 이중화된 DBMS 장애 발생 시 처리 방법과 원상 복구 방법에 대해 알아보겠습니다.