처음 사용자를 위한 PostgreSQL 사용 샘플 - 6. Replication - WAL Streaming

"처음 사용자를 위한 PostgreSQL 사용 샘플"이라는 제목의 시리즈로, 저처럼 PostgreSQL을 처음 접하는 사용자를 위한 기본적인 개념, 사용 샘플을 설명드립니다.

이전글

[Database/PostgreSQL] - 처음 사용자를 위한 PostgreSQL 사용 샘플 - 5. 데이터 업로드

 

아래 자료를 참조했습니다.

PostgreSQL Domcumentation
The Internals of PostgreSQL
PostgreSQL Tutorial

---

PostgreSQL의 High Availability 아키텍처

PostgreSQL에서는 Active-Standby의 Replication 방식 High Availability (HA) 아키텍처를 제공합니다. Write-Ahead Logging (WAL) 레코드라는 것을 이용하는데, WAL 이란 (30.3. Write-Ahead Logging (WAL)) 데이터 정합성 보장 방식으로 변경 사항이 로깅된 이후에라야 데이터 파일에 이를 기록해야하는 것으로, 이러한 WAL 레코드는 영구 스토리지에 이후에 flush 됩니다. WAL 레코드는 오라클 데이터베이스의 Redo 로그라고 보시면 됩니다.

 

PostgreSQL Replication은 Primary 서버에 장애가 발생했을 때 하나 또는 여러개의 Standby 서버가 Primary 서버의 오퍼레이션을 대신하는 방식으로 Warm Standby, Log Shipping 방식이라고 부르며, 이때 WAL 레코드를 사용합니다. 그리고 데이터베이스의 WAL 레코드를 다른 데이터베이스로 옮기는 작업을 Log Shipping 이라고 부릅니다. 여기에는 16MB 사이즈의 WAL 파일을 옮기는 파일 기반 Log Shipping과 WAL 변경 내용을 스트리밍하는 좀 더 세분화된 방식의 레코드 기반 Log Shipping이 있으며, 특히 레코드 기반 Log Shipping을 Streaming 방식이라고 부릅니다.

 

고려할 사항은 트랜잭션 레코드가 Standby 서버로 옮겨지기 전에 Primary 서버에 장애가 발생하게면 아직 전달되지 않은 트랜잭션은 손실됩니다.

• 파일 기반 Log Shipping: archive_timeout 파라미터로 데이터 손실 범위를 조정. 초 단위로 낮게 잡으면 데이터 손실 범위는 작으나, 네트웍 대역폭 사용량이 증가
• 레코드 기반 Log Shipping (Streaming): 파일 기반 Log Shipping에 비해 훨씬 작은 데이터 손실 허용

위에서 언급한 Log Shipping 외에도 PostgreSQL에서는 Logical Replication을 지원합니다. Logical Replication은 블록 레벨의 바이트 단위의 복제인 Physical Replication과 대비되는 것으로 복제 식별자 (보통 Primary Key)를 기반으로 데이터 오브젝트와 변경 사항을 복제하는 방식입니다.

Logical Replication은 PUBLISH-SUBSCRIBE 모델을 사용합니다. 하나 또는 여러개의 Publisher가 역시 하나 또는 여러개의 Subscriber에게 서비스하는 형태로 Subscriber는 Publisher에게서 가져온 데이터를 다시 Re-publish 하는 Cascading 방식을 사용할 수도 있습니다. 상세 내용은 아래 링크를 참조하세요. Chapter 31. Logical Replication

 

PostgreSQL의 Streaming 방식 Replication 구성

PostgreSQL에서는 Active-Standby의 Replicat

여기에서는 레코드 기반 Log Shipping (Streaming)을 구성해 보겠습니다.

아래 글을 테스트에 참조했습니다.

SETTING UP POSTGRESQL STREAMING REPLICATION

이번 테스트에서는 Primary DB (호스트명: dbnode1 / IP: 10.0.30.2)에서 Standby DB (호스트명: dbnode2 / IP: 10.0.30.3) 으로 Streaming 방식의 Replication을 구성했습니다.

 

먼저 Standby 노드에도 PostgreSQL을 설치합니다. 설치 방법은 아래 이전 글을 참조하시면 됩니다.

[Database/PostgreSQL] - PostgreSQL from Oracle's point of view - 2. PostgreSQL 설치

 

Primary, Standby 노드에 PostgreSQL이 기동 중인지 확인합니다.

 

Primary 노드에서 수행

PostgreSQL Replication에서는 Standby 노드에서 Primary 노드로 접속할 때 5432 포트를 사용합니다. 따라서 Primary 노드에서 5432 포트를 개방해 주어야 합니다. 여기서는 지난 테스트에서 아래와 같이 이미 5432 포트를 개방했기 때문에 추가 작업을 하지는 않았습니다. OCI 환경이라 OCI VCN 레벨에서도 인터넷으로 부터 5432 포트를 개방했고, Primary, Standby 노드가 사용하는 10.0.30.0/24 서브넷 내에서는 모든 통신이 가능하도록 미리 설정했습니다.

 

지난 글에서도 언급한바와 같이 PostgreSQL을 설치하면 기본값이 로컬 호스트 내에서만 5432 포트 접속이 가능합니다. Standby에서 Primary DB로 접속하기 위해서는 원격 접속을 허용해야하는데, PostgreSQL 설정 파일 "postgresql.conf"에서 listen_addresses = '*' 와 같이 변경해 주어야 합니다.

이 역시 지난 글에서 이미 작업한 내용이므로 이번에는 추가 작업을 하지 않습니다. 아래 지난 글을 참조하세요.

[Database/PostgreSQL] - 처음 사용자를 위한 PostgreSQL 사용 샘플 - 4. pgAdmin 설치 & DB 접속

 

이제 Replication에서 사용될 DB 유저를 만들 차례입니다. 일반적으로 복제를 위한 유저를 분리하는 것이 보안을 위해 권고됩니다. "CREATE USER repuser REPLICATION;" 명령으로 복제용 DB 유저를 생성합니다. 테스트의 편이를 위해 별도 유저의 패스워드를 설정하지는 않았습니다.

 

앞서 한 "postgresql.conf" 수정과 함께 "pg_hba.conf" 설정 파일에서 접속을 허용할 Standby 노드의 IP (또는 IP대역)과 생성한 DB 유저를 지정해 주어야 합니다. "vi /var/lib/pgsql/14/data/pg_hba.conf/pg_hba.conf" 설정 파일 맨아래 아래 내용을 추가합니다.

host replication repuser 10.0.30.3/24 trust

 

설정 파일을 변경했기 때문에 "systemctl restart postgresql-14" 명령으로 PostgreSQL을 다시 시작합니다.

 

Standby 노드에서 수행

이제 Primary 노드에서의 설정이 모두 끝났습니다. 지금부터는 Standby 노드에서의 작업입니다.

먼저 Standby DB를 Primary DB의 복제본으로 만드는 것이 필요합니다. 이를 위해서 "systemctl stop postgresql-14" 명령으로 Standby DB를 중지시키고, 데이터 디렉토리를 비우는 "rm -rf /var/lib/pgsql/14/data/" 작업을 합니다. 

 

postgres 유저로 로그인하여 Standby DB에서 "pg_basebackup" 유틸리티를 이용해서 Primary DB로 접속하여 모든 데이터파일을 복사해 오는 작업을 수행합니다. "pg_basebackup -h 10.0.30.2 -U repuser --checkpoint=fast -D /var/lib/pgsql/14/data/ -R --slot=some_name -C" 명령으로 수행합니다.

pg_basebackup 각 옵션의 의미는 다음과 같습니다.

• -h: Primary 호스트
• -U: Replication DB 유저
• -D: Standby DB 상의 데이터 저장 위치 디렉토리
• -R: 복제를 위한 Standby DB 설정을 자동으로 수행
• --checkpoint=fast: 빠른 체크포인트 수행
• --slot=some_name: Replication Slot 설정. 기본적으로 WAL은 Primary에서 더 이상 사용되지 않게 되면 재사용됨. 그러나 Standby가 Primary의 WAL을 아직 반영하지 않은 상태에서 재사용 되게 되면 데이터의 유실이 발생하게 됨. Replication Slot은 Standby에 WAL이 반영된 이후에만 Primary WAL을 재활용할 수 있도록 하는 역할을 하고, "--slot=some_name" 는 Replication Slot이 없으면 Standby가 실패하도록 하는 설정

 

Standby DB 데이터 디렉토리 "/var/lib/pgsql/14/data/"를 조회해 보면 Primary DB 데이터가 복사되어 있음을 알 수 있습니다. 디렉토리 내 파일 중 Prmary DB에는 없는 "standby.signal" 파일이 새로 생성되어 있는데, 이는 복제본이라는 의미입니다.

 

그리고 "postgresql.auto.conf" 파일 내용을 보면, Primary DB로 접속하기 위한 정보가 추가된 것을 알 수 있습니다.

 

끝으로 "systemctl start postgresql-14" 명령으로 Standby DB를 시작합니다. 

 

Replication 설정 확인

이제 Primary, Standby 양쪽 노드의 프로세스를 확인해 보면 Primary 노드에는 "walsender" 프로세스가, Standby 노드에는 "walreceiver" 프로세스가 떠 있는 것을 볼 수 있습니다.

 

PostgreSQL이 제공하는 메타 정보에서도 Replication 구성/운영 상태를 확인할 수 있습니다. Primary DB에서 "select * from pg_stat_replication;", Standby DB에서는 "select * from pg_stat_wal_receiver;" 와 같이 조회해서 아래와 같이 이를 확인할 수 있습니다.

 

실제 Primary DB에서 입력한 데이터가 Standby DB에서도 반영되는지 보겠습니다. Primary DB에서 이전에 업로드한 dvdrental DB로 접속하여 "insert into country values (10000,'MyKingdom',now());"와 같이 데이터를 한건 입력합니다.

 

Standby DB에서 "select * from country where country_id=10000;" 쿼리로 확인해보면 Primary DB에서 입력된 데이터가 반영되어 있음을 알 수 있습니다.

 

<끝>