PostgreSQL 복제 마스터하기: 유형 및 설정 방법 해설

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

고급 오픈 소스 관계형 데이터베이스 세계에서 PostgreSQL은 견고성, 확장성 및 강력한 기능으로 두각을 나타냅니다. 이 중 데이터 중복성과 고가용성은 중요 애플리케이션에 매우 중요합니다. PostgreSQL 복제는 한 PostgreSQL 서버(주 서버)의 데이터를 하나 이상의 다른 PostgreSQL 서버(복제본 또는 대기 서버)로 복사하여 이러한 목표를 달성할 수 있게 하는 메커니즘입니다.

이 글에서는 PostgreSQL 복제의 핵심 개념을 살펴보고, 사용 가능한 다양한 유형을 탐구하며, 설정 방법에 대한 실용적인 지침을 제공합니다. 이러한 메커니즘을 이해하는 것은 데이터가 항상 액세스 가능하고, 하드웨어 장애로부터 보호되며, 증가하는 읽기 부하를 처리할 수 있는지 확인하는 데 중요합니다. 스트리밍 복제와 논리 복제 모두를 다루며, 사용 사례, 장점 및 구성 단계를 설명합니다.

PostgreSQL 복제가 중요한 이유

'방법'을 자세히 알아보기 전에 '이유'를 이해하는 것이 중요합니다. 데이터 손실 또는 장시간의 다운타임은 비즈니스에 심각한 결과를 초래할 수 있습니다. 복제는 다음과 같은 방법으로 이러한 문제를 해결합니다.

고가용성(HA): 주 서버에 장애가 발생하면 복제본을 새 주 서버로 신속하게 승격하여 다운타임을 최소화할 수 있습니다.
재해 복구(DR): 복제본을 다른 지리적 위치에 배치하여 특정 위치의 재해로부터 데이터를 보호할 수 있습니다.
읽기 확장성: 읽기 위주의 워크로드를 복제본으로 오프로드하면 쓰기 작업 전용인 주 서버의 성능을 향상시킬 수 있습니다.
데이터 보호: 복제는 지속적인 백업 역할을 하며, 전통적인 주기적 백업보다 최신 데이터 복사본을 제공합니다.

PostgreSQL은 복제를 위해 두 가지 기본 방법을 제공합니다: 스트리밍 복제와 논리 복제. 둘 다 데이터 동기화를 달성하지만, 서로 다른 원칙으로 작동하며 서로 다른 시나리오에 적합합니다.

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

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

스트리밍 복제 유형:

동기 복제: 동기 모드에서 주 서버는 트랜잭션 커밋을 클라이언트에 확인하기 전에 최소 하나(또는 지정된 수)의 복제본으로부터 WAL 레코드가 수신되어 WAL 버퍼에 기록되었다는 확인을 기다립니다. 이는 커밋된 트랜잭션이 최소한 하나의 복제본에 존재함을 보장하여 데이터 일관성의 최고 수준을 제공합니다.
- 장점: 동기 복제본에 대한 커밋된 트랜잭션의 데이터 손실이 발생하지 않음을 보장합니다.
- 단점: 주 서버가 복제본의 확인을 기다려야 하므로 트랜잭션 커밋 지연이 발생할 수 있습니다.
비동기 복제: 비동기 모드에서 주 서버는 WAL 레코드를 복제본으로 보내지만, 커밋 시 확인을 기다리지 않습니다. 주 서버는 WAL을 로컬에 기록한 후 즉시 클라이언트에 커밋을 확인합니다. 이는 지연 시간이 짧지만, 주 서버가 WAL 레코드가 복제본으로 전송 및 적용되기 전에 실패할 경우 데이터 손실 위험이 있습니다.
- 장점: 트랜잭션 커밋 지연에 미치는 영향이 최소화됩니다.
- 단점: 주 서버가 실패하고 WAL 레코드가 아직 복제본에 도달하지 않은 경우 데이터 손실 가능성이 있습니다.

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

스트리밍 복제 설정에는 주 서버와 복제 서버 모두를 구성하는 것이 포함됩니다. 다음은 간소화된 가이드입니다.

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

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

postgresql.conf 수정:

```ini
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 = 'cp %p /path/to/wal_archive/%f'
`` *wal_level: 스트리밍 복제의 경우 최소replica여야 합니다. *max_wal_senders: 동시에 몇 개의 대기 서버가 연결될 수 있는지 지정합니다. *wal_keep_size: 복제본이 가져갈 수 있기 전에 WAL 파일이 삭제되는 것을 방지합니다(기본 설정의 간단한 대안이지만, 견고성을 위해 아카이빙이 권장됨). *archive_mode&archive_command`: 특정 시점 복구(PITR)에 중요하며, 복제본이 너무 뒤처지거나 다시 구축해야 하는 경우 필수적입니다.
pg_hba.conf 수정:

복제본이 복제를 위해 연결하도록 허용합니다. replica_ip_address를 복제본의 실제 IP로 바꾸십시오.

```ini

TYPE DATABASE USER ADDRESS METHOD

host replication replication_user replica_ip_address/32 md5
```

복제 사용자도 만들어야 합니다:

sql -- 주 서버에서: CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';

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

```bash
pg_ctl reload

필요한 경우 PostgreSQL을 다시 시작합니다

```

2. 복제 서버 준비

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

복제 서버에서 PostgreSQL 중지 (실행 중인 경우).
기본 백업 수행:

```bash

PGDATA가 비어 있거나 먼저 제거되었는지 확인

pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P
`` *-h,-p,-U: 주 서버의 연결 세부 정보를 지정합니다. *-D: 복제본의 데이터 디렉토리입니다. *-Fp: 형식은 일반입니다. *-Xs: 스트림 TSL/WAL 스트리밍을 사용합니다.primary_conninfo설정 WAL 스트리밍과 동일합니다. *-P: 진행 상황을 표시합니다. *replication_user`의 비밀번호를 묻는 메시지가 표시됩니다.

3. 복제 서버 구성(`postgresql.conf` 및 `recovery.conf` 또는 PG12+의 경우 `postgresql.conf`)

postgresql.conf 수정 (PG12+의 경우):

```ini
hot_standby = on # 복제본에서 읽기 전용 쿼리 허용
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'

동기 복제의 경우 추가:

primary_promote_delay = 10 # 초

또는 트리거 파일 메커니즘 사용

`` *hot_standby: 대기 서버에서 읽기 전용 쿼리를 활성화합니다. *primary_conninfo`: 주 서버에 대한 연결 문자열입니다.
recovery.conf (12 미만 PostgreSQL 버전의 경우):

복제본의 데이터 디렉토리에 다음 내용으로 recovery.conf 파일을 만듭니다.

```ini
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'

```

PG12+의 경우 primary_conninfo 및 hot_standby는 postgresql.conf에 직접 설정됩니다.

4. 복제 서버 시작

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

팁: 견고한 HA를 위해 Patroni 또는 repmgr와 같은 도구를 사용하는 것을 고려하십시오. 이 도구들은 장애 조치 및 관리를 자동화합니다.

논리 복제

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

주요 기능 및 사용 사례:

선택적 복제: 복제할 테이블 또는 심지어 특정 열을 선택할 수 있습니다. 이는 데이터베이스 간에 데이터를 선택적으로 이동하는 데 매우 유용합니다.
교차 버전 복제: 논리 복제는 PostgreSQL의 다른 주요 버전 간에 데이터를 복제할 수 있습니다.
선택적 스키마 변경: 특정 데이터베이스 또는 스키마에 대한 변경 사항을 복제할 수 있으며, 특정 테이블만 게시할 수도 있습니다.
데이터 변환: 내장되어 있지 않지만, 논리 복제는 더 복잡한 ETL(추출, 변환, 로드) 프로세스를 위한 기반을 제공합니다.
주 서버에서 전체 복제본이 아닌 복제본으로 복제: 대상 데이터베이스가 소스의 완전한 물리적 복사본일 필요는 없습니다.

작동 방식:

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

논리 복제 설정

1. 게시자(주 서버) 구성

postgresql.conf 수정:

ini wal_level = logical max_replication_slots = 10 # 논리 복제 슬롯의 경우 max_wal_senders = 10 # max_replication_slots 이상이어야 함
게시 생성:

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

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

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

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

대상 테이블이 존재하는지 확인: 구독자 데이터베이스에는 게시자와 동일한 스키마를 가진 대상 테이블이 있어야 합니다. 수동으로 생성하거나 pg_dump를 사용하여 스키마를 추출할 수 있습니다.
구독 생성:

sql -- 구독자 데이터베이스에서: 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을 사용하여 구독 상태를 모니터링할 수 있습니다.

팁: 논리 복제는 일반적으로 내장된 logical decoding 확장이 필요합니다. 스트리밍 복제보다 리소스 집약적이지만 더 큰 유연성을 제공합니다.

올바른 복제 방법 선택

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

결론

PostgreSQL 복제는 강력한 데이터 가용성, 복구 및 확장성을 가능하게 하는 강력한 기능입니다. 스트리밍 복제의 포괄적인 데이터 미러링을 선택하든, 논리 복제의 유연하고 선택적인 접근 방식을 선택하든, 해당 메커니즘과 구성을 이해하는 것이 안정적이고 복원력 있는 PostgreSQL 환경을 유지하는 데 중요합니다. 복제를 구현함으로써 데이터베이스의 내결함성과 성능 기능을 크게 향상시킬 수 있습니다.

항상 복제 설정, 특히 장애 조치 시나리오를 철저히 테스트하고 복제 지연을 모니터링하여 복제본이 최신 상태인지 확인하십시오. PostgreSQL의 발전하는 기능에 대한 지속적인 학습과 적응은 이 필수 데이터베이스 시스템에 대한 숙련도를 더욱 공고히 할 것입니다.

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

PostgreSQL 복제가 중요한 이유

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

스트리밍 복제 유형:

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

1. 주 서버 구성(postgresql.conf 및 pg_hba.conf)

동기 복제의 경우 추가:

synchronous_standby_names = 'replica1,replica2'

또는 특정 서버 이름/우선 순위의 경우:

synchronous_standby_names = '1 (replica1), 2 (replica2)'

TYPE DATABASE USER ADDRESS METHOD

필요한 경우 PostgreSQL을 다시 시작합니다

2. 복제 서버 준비

PGDATA가 비어 있거나 먼저 제거되었는지 확인

3. 복제 서버 구성(postgresql.conf 및 recovery.conf 또는 PG12+의 경우 postgresql.conf)

동기 복제의 경우 추가:

primary_promote_delay = 10 # 초

또는 트리거 파일 메커니즘 사용

스트리밍 대신 아카이브 복구를 사용하는 경우 restore_command를 지정해야 합니다.

restore_command = 'cp /path/to/wal_archive/%f %p'

recovery_target_timeline = 'latest'