PostgreSQL 복제 마스터하기: 유형 및 설정 설명

PostgreSQL 복제는 보조 서버를 기본 서버에 충분히 가깝게 유지하여 하드웨어 장애에서 살아남거나, 읽기 트래픽을 전환하거나, 통제된 마이그레이션을 실행할 수 있게 해줍니다. 데이터베이스가 프로덕션 의존성이라면, 노드가 실패하기 전에 어떤 PostgreSQL 복제 모델이 위험 허용 범위에 맞는지 알아야 합니다.

PostgreSQL은 두 가지 일반적인 선택지를 제공합니다: 스트리밍 복제와 논리적 복제. 스트리밍 복제는 물리적 클러스터 수준에서 WAL을 복사합니다. 논리적 복제는 게시 및 구독을 통해 선택된 테이블에서 행 수준 변경 사항을 보냅니다.

PostgreSQL 복제가 중요한 이유

복제는 네 가지 일상적인 운영 문제를 해결하는 데 도움이 됩니다:

고가용성: 기본 서버에 장애가 발생하면 대기 서버를 승격하고 애플리케이션을 그쪽으로 연결할 수 있습니다.
재해 복구: 다른 위치에 있는 대기 서버는 사이트 수준 장애로부터 보호할 수 있습니다.
읽기 확장: 읽기 전용 쿼리는 쓰기 기본 서버 대신 핫 대기 서버에 대해 실행할 수 있습니다.
마이그레이션 지원: 논리적 복제는 PostgreSQL 버전이나 데이터베이스 레이아웃 간에 선택된 테이블을 이동하는 데 도움이 될 수 있습니다.

복제는 백업을 대체하지 않습니다. 버그, 잘못된 마이그레이션 또는 실수로 인한 DELETE는 빠르게 복제될 수 있습니다. 복제와 함께 테스트된 백업 및 특정 시점 복구를 유지하세요.

스트리밍 복제 (물리적 복제)

스트리밍 복제는 PostgreSQL에서 가장 일반적이고 기본적인 복제 형태입니다. 기본 서버에서 하나 이상의 복제본으로 Write-Ahead Log(WAL) 레코드를 전송하여 작동합니다. 이러한 WAL 레코드는 데이터베이스에 대한 모든 변경 사항을 나타냅니다. 그런 다음 복제본은 이러한 WAL 레코드를 자체 데이터 파일에 적용하여 기본 서버와 일관성을 유지합니다.

동기식 vs 비동기식 스트리밍

동기식 복제는 기본 서버가 클라이언트에 커밋을 보고하기 전에 하나 이상의 동기식 대기 서버를 기다리게 합니다. 정확한 안전 수준은 synchronous_commit에 따라 다릅니다. 예를 들어, WAL이 기록될 때까지 기다리는 것은 재생될 때까지 기다리는 것과 다릅니다. 승인된 커밋 손실에 대한 더 강력한 보호를 제공하지만, 모든 커밋은 이제 복제본 및 네트워크 지연 시간에 의존합니다.

비동기식 복제는 기본 서버가 로컬로 커밋하고 나중에 복제본에 WAL을 보낼 수 있도록 합니다. 쓰기 속도는 더 빠르지만, 기본 서버 충돌 시 아직 대기 서버에 도달하지 않은 최근 트랜잭션이 손실될 수 있습니다.

스트리밍 복제 설정 (비동기식 예제)

스트리밍 복제를 설정하려면 기본 서버와 복제본 서버를 모두 구성해야 합니다. 다음은 간단한 가이드입니다:

1. 기본 서버 구성 (`postgresql.conf` 및 `pg_hba.conf`)

기본 서버에서 WAL 아카이빙 및 복제 연결을 활성화해야 합니다.

postgresql.conf 수정:
```
wal_level = replica  # 논리적 복제의 경우 logical
max_wal_senders = 5  # 동시 복제 연결 수
wal_keep_size = 512MB # 이전 버전의 경우 wal_keep_segments
# 동기식 복제의 경우 다음을 추가:
# synchronous_standby_names = 'replica1,replica2'
# 또는 특정 서버 이름/우선 순위:
# synchronous_standby_names = '1 (replica1), 2 (replica2)'
archive_mode = on
archive_command = 'test ! -f /path/to/wal_archive/%f && cp %p /path/to/wal_archive/%f'
```
- wal_level: 스트리밍 복제를 위해 최소한 replica여야 합니다.
- max_wal_senders: 동시에 연결할 수 있는 대기 서버 수를 지정합니다.
- wal_keep_size: 복제본이 가져오기 전에 WAL 파일이 삭제되는 것을 방지합니다(기본 설정의 경우 archive_command보다 간단한 대안이지만, 안정성을 위해 아카이빙을 권장합니다).
- archive_mode 및 archive_command: 특정 시점 복구(PITR) 및 뒤처진 후 이전 WAL이 필요한 복제본에 유용합니다. 프로덕션에서는 로컬 복사 명령 대신 실제 아카이브 대상 또는 백업 도구를 사용하세요.

pg_hba.conf 수정:

복제본이 복제를 위해 연결할 수 있도록 허용합니다. replica_ip_address를 복제본의 실제 IP로 바꾸세요.

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replication_user  replica_ip_address/32   md5

또한 복제 사용자를 생성해야 합니다:

-- 기본 서버에서:
CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';

이러한 파일을 수정한 후 PostgreSQL 구성을 다시 로드합니다:

pg_ctl reload
# 또는 필요한 경우 PostgreSQL을 다시 시작합니다.

2. 복제본 서버 준비

복제본을 시작하기 전에 특정 시점의 기본 서버 데이터 디렉터리 복사본인 데이터 디렉터리가 있어야 합니다. 가장 쉬운 방법은 pg_basebackup을 사용하는 것입니다.

복제본에서 PostgreSQL을 중지합니다(실행 중인 경우).
기본 백업을 수행합니다:
```
# PGDATA가 비어 있거나 먼저 제거되었는지 확인
pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P -R
```
- -h, -p, -U: 기본 서버의 연결 세부 정보를 지정합니다.
- -D: 복제본의 데이터 디렉터리입니다.
- -Fp: 형식은 일반(plain)입니다.
- -Xs: 백업 중에 WAL을 스트리밍합니다.
- -P: 진행 상황을 표시합니다.
- -R: 대기 연결 설정을 작성하고 PostgreSQL 12 이상용 standby.signal을 생성합니다.
- replication_user의 비밀번호를 묻는 메시지가 표시됩니다.

3. 복제본 서버 구성

postgresql.conf 수정 (PG12+):
```
hot_standby = on # 복제본에서 읽기 전용 쿼리 허용
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
```
- hot_standby: 대기 서버에서 읽기 전용 쿼리를 활성화합니다.
- primary_conninfo: 기본 서버에 대한 연결 문자열입니다.
이전 PostgreSQL 버전:

PostgreSQL 12는 recovery.conf를 제거했습니다. 이전 서버를 유지 관리하는 경우 복제본 데이터 디렉터리에 recovery.conf를 생성하세요:
```
standby_mode = 'on'
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
# 스트리밍 대신 아카이브 복구를 사용하는 경우 restore_command를 지정합니다.
# restore_command = 'cp /path/to/wal_archive/%f %p'
# recovery_target_timeline = 'latest'
```
PostgreSQL 12 이상에서는 대기 모드가 standby.signal에 의해 제어되며, primary_conninfo는 일반적으로 pg_basebackup -R로 생성될 때 postgresql.auto.conf에 있습니다.

4. 복제본 서버 시작

복제본에서 PostgreSQL 서비스를 시작합니다. 기본 서버에 연결하고, WAL 레코드를 수신하고, 동기화를 시작합니다. 확인을 위해 로그를 확인할 수 있습니다.

팁: 강력한 HA를 위해 장애 조치 및 관리를 자동화하는 Patroni 또는 repmgr과 같은 도구 사용을 고려하세요.

논리적 복제

논리적 복제는 PostgreSQL 10에 도입된 보다 유연하고 세분화된 복제 형태입니다. 전체 데이터 블록이나 WAL 레코드를 복제하는 대신 행 수준에서 논리적 의미(예: INSERT, UPDATE, DELETE 문)를 기반으로 데이터 변경 사항을 복제합니다. 이는 WAL 레코드를 논리적 변경 사항 스트림으로 디코딩하여 달성됩니다.

주요 기능 및 사용 사례:

선택적 복제: 복제할 테이블을 선택할 수 있습니다. 최신 PostgreSQL 버전은 게시의 열 목록도 지원하지만, 해당 기능에 의존하기 전에 서버 버전을 확인하세요.
교차 버전 복제: 논리적 복제는 PostgreSQL의 다른 주요 버전 간에 데이터를 복제할 수 있습니다.
스키마 제어: 논리적 복제는 DDL을 자동으로 복제하지 않습니다. 일치하는 테이블을 만들고 구독자에 스키마 마이그레이션을 적용하세요.
데이터 변환: 기본 제공되지는 않지만 논리적 복제는 더 복잡한 ETL(추출, 변환, 로드) 프로세스를 위한 기반을 제공합니다.
전체 복제본이 아닌 기본 서버에서 복제본으로 복제: 대상 데이터베이스가 소스의 완전한 물리적 복사본일 필요는 없습니다.

작동 방식:

게시자: 데이터 변경이 발생하는 소스 데이터베이스(기본 서버). wal_level = logical이 필요합니다. 변경 사항은 WAL에서 논리적 스트림으로 디코딩됩니다.
게시: 게시자에서 변경 사항이 복제될 명명된 테이블 집합입니다.
구독자: 변경 사항을 수신하는 대상 데이터베이스(복제본)입니다.
구독: 구독자에서 게시자에 연결하고 특정 게시의 변경 사항을 적용하는 연결입니다.

논리적 복제 설정

1. 게시자 구성 (기본 서버)

postgresql.conf 수정:

wal_level = logical
max_replication_slots = 10 # 논리적 복제 슬롯용
max_wal_senders = 10     # 최소한 max_replication_slots 이상이어야 함

게시 생성:

-- 게시자 데이터베이스에서:
CREATE PUBLICATION my_publication FOR TABLE 
    table1, 
    table2 
    WITH (publish = 'insert,update,delete');

-- 또는 모든 테이블의 경우:
-- CREATE PUBLICATION all_tables_pub FOR ALL TABLES;

게시자에서 구성을 다시 로드합니다.

2. 구독자 구성 (복제본 서버)

대상 테이블이 존재하는지 확인: 구독자 데이터베이스에는 게시자와 동일한 스키마를 가진 대상 테이블이 있어야 합니다. 수동으로 생성하거나 pg_dump를 사용하여 스키마를 추출할 수 있습니다.
구독 생성:
```
-- 구독자 데이터베이스에서:
CREATE SUBSCRIPTION my_subscription
    CONNECTION 'host=publisher_host_ip port=5432 user=replication_user password=your_password dbname=publisher_db'
    PUBLICATION my_publication;
```
replication_user는 게시자에 대한 적절한 권한이 필요합니다.

PostgreSQL은 게시자에 복제 슬롯을 자동으로 생성하고 변경 사항 적용을 시작합니다. 구독자에서 pg_stat_subscription을 사용하여 구독 상태를 모니터링할 수 있습니다.

팁: 논리적 복제는 PostgreSQL의 내장 논리적 디코딩 인프라를 사용합니다. 기본 게시 및 구독에 별도의 확장이 필요하지 않습니다.

올바른 복제 방법 선택

스트리밍 복제: 기본 서버의 정확한 바이트 단위 복사본이 필요한 고가용성 및 재해 복구에 이상적입니다. 전체 데이터베이스 복제를 설정하기가 더 간단하며 읽기 전용 복제본에 최상의 읽기 확장성을 제공합니다.
논리적 복제: 선택적 데이터 배포, 마이그레이션, 교차 버전 업그레이드 또는 데이터 하위 집합만 복제해야 하는 경우에 가장 적합합니다. 다른 스키마로 복제하거나 데이터 변환을 수행하는 것과 같은 더 복잡한 시나리오를 허용합니다.

핵심 내용

장애 조치, 재해 복구 또는 읽기 전용 트래픽을 위해 전체 대기 서버가 필요한 경우 스트리밍 복제를 사용하세요. 선택된 테이블, 교차 버전 마이그레이션 또는 다른 데이터베이스 간의 제어된 데이터 이동이 필요한 경우 논리적 복제를 사용하세요.

어느 설정을 신뢰하기 전에 장애 조치 훈련을 실행하고, 애플리케이션 연결 처리를 확인하고, 복제 지연을 모니터링하고, 백업이 여전히 깔끔하게 복원되는지 확인하세요. 복제는 다른 서버를 최신 상태로 유지합니다. 운영 테스트를 대체하지는 않습니다.