Replication은 Data 저장과 백업하는 방법과 관련이 있는 Data를 호스트 컴퓨터에서 다른 컴퓨터로 복사하는 것을 말한다. Replication은 RDBMS에서 추가적으로 제공하거나 여러 대의 Database Server의 부하를 맞추어 줄 용도로 제공한다. Database Replication에서 사용되는 것은 대부분 Database 관리 영역인데 보통 Master/Slave 관계를 갖는 원본과 복사본 사이를 다룬다.— 위키백과 (Replication)
Database Replication
Database를 Replication(복제)하는 이유는 크게 Database의 부하분산(Load Balancing), 고가용성(High Availability), 백업등으로 나눌 수 있습니다.
Main Database에서 DDL, DML 등의 여러 작업을 처리하면 Database에 부하가 발생할 수 있습니다. 이때, 하나 이상의 읽기 전용 Standby Database를 둔다면, SELECT Query에 대한 분산처리를 유도하여 Database를 보다 안정적으로 운영할 수 있습니다.
또한 Main Database의 장애발생 시 Standby Database로 Failover 하면 예기치 못한 장애상황도 빠르게 대처가능합니다.
이처럼, 사용자는 여러 가지 이유로 Database Replication 구성을 고려합니다. PostgreSQL 역시 다양한 Replication 방식을 제공하며, 별도의 솔루션 없이도 환경에 맞게 자유로운 구성이 가능합니다.
📢 일반적으로 Database Replication의 원본과 복사본을 지칭하는 용어는 매우 다양하며 이를 혼용해서 사용됩니다. 원본 Server를 Main, Master, Primary, Publisher, Active 등의 용어로 사용하며, 복제되는 Server를 Standby, Slave, Secondary, Subscripber 같은 용어로 표현합니다. 본 문서를 포함한 해당 Series에서는 원본을 의미하는 Server는 Main Server, 복사본을 의미하는 Server는 Standby Server로 사용합니다.
Write-Ahead Log
PostgreSQL Replication을 설명하기 앞서 Write-Ahead Log(이하 WAL)에 대한 내용을 이해해야 합니다. 이는 대부분의 Replication이 WAL Log를 기반으로 동작하기 때문입니다.
용어의 차이는 있지만, WAL이란 데이터무결성을 보장하는 DBMS 표준방법으로, 변경내용을 설명하는 Log Record를 저장소에 먼저 기록한 후, 이후에 Data 파일에 변경내용을 적용하는 방식으로 동작합니다.
PostgreSQL의 WAL Log는 Oracle의 Redo-Archive와 비슷한 역할을 합니다. Database Crash 발생 시 WAL Log를 사용하여 Database 복구를 할 수 있습니다.
이러한 WAL은 Database에 발생한 변경내역을 기록한 일종의 명세서로, 그 특징을 활용해 Standby Server에 변경내역(WAL)을 Replay 하는 용도로 사용됩니다.
Write-Ahead Log를 사용하는 이유
- 트랜잭션 Commit 마다 Data Page를 디스크에 기록할 필요가 없다.
- Data Page에 적용되지 않은 변경 내용은 Log Record에서 실행 취소가 가능하다.
- Log 파일은 순차적으로 작성되며, Log 파일 동기화 비용은 Data Page 쓰기 비용보다 훨씬 적다.
- 소규모의 트랜잭션을 대량으로 처리하는 경우, Log 파일의 fsync 하나로 여러 가지 트랜잭션을 충분히 Commit 할 수 있다.
- 온라인 백업 및 PITR(Point-In-Time Recovery) 지원이 가능하다.
📢 fsync는 Buffer에 저장된 Data를 디스크로 저장할 때 호출하는 함수입니다. Data와 Metadata의 변경 파일을 하드 디스크에 저장되도록 요청하며, 저장이 완료될 때까지 대기합니다.
PostgreSQL Replication 종류
PostgreSQL의 Replication은 방식에 따라 여러 종류가 존재합니다. 본 문서에서는 다루지 않지만 하나의 디스크를 여러 개의 PostgreSQL Server가 공유하는 Shared Disk Failover 방식, 디스크는 별개로 사용하되 File System Level로 복제하는 File System Replication 방식이 있습니다. 그리고 PostgreSQL 자체적으로 Replication을 지원하기도 하며, 3rd Party 솔루션을 사용할 수도 있습니다. 각각의 Replication방식은 그 특징과 장/단점이 명확하므로 특성을 파악한 후 적절한 Replication 방식을 사용해야 합니다.
이 중, 본 문서에서는 아래와 같이 PostgreSQL 자체적으로 제공하는 Replication 기능에 대해 알아보겠습니다.
PostgreSQL Replication은 크게 Physical Replication과 Logical Replication으로 구분할 수 있습니다.
Physical Replication은 ① WAL 파일 자체를 전달하는 File-based Log Shipping과 ② WAL 파일 저장 여부와 상관없이 WAL Record를 전달하는 Streaming Replication으로 구분할 수 있습니다. 이 중 File-based Log Shipping방식의 경우 PostgreSQL에서 버전에 따라 Warm Standby와 Hot Standby로 구분됩니다.
📢 PostgreSQL 9.6 버전까지는 Transaction Log Shipping이라는 명칭으로 사용되었지만, PostgreSQL 10 버전부터 Write-Ahead Log Shipping으로 변경되었습니다.
📢 하나의 WAL 파일은 여러 개의 WAL Record로 구성됩니다. 변경작업이 발생할 때, 하나의 변경작업은 하나의 WAL Record로 볼 수 있습니다. 이러한 WAL Record는 pg_waldump 응용프로그램을 내용을 확인할 수 있습니다.
Logical Replication은 PostgreSQL 10 버전에서 소개되었으며, Physical Replication의 한계를 해결하기 위한 목적으로 도입되었습니다. Physical Replication과 마찬가지로 WAL을 기반으로 작동하지만, DML 발생 시 walsender 프로세스가 WAL Record를 Logical Decoding 처리한 후 전송한다는 차이가 존재합니다.
📢 Logical Decoding은 Table에 대한 모든 변경사항을 Database Architecture와 상관없이 해석가능한 일관되고 이해하기 쉬운 형식으로 추출하는 프로세스입니다. PostgreSQL에서는 WAL 내용을 Tuple 또는 SQL문과 같은 응용프로그램 형식으로 디코딩하여 구현됩니다.
File-based Log Shipping
Physical Replication의 종류 중 하나인 File-based Log Shipping은 완성된 WAL 파일을 Standby Server로 전달, Recovery 작업을 통해 Replication 하는 방식입니다. 즉, Main Server의 WAL 파일이 정해진 크기(Default : 16MB)를 다 채운 후 새로운 파일이 생성되어야 비로소 기존 WAL 파일에 대한 전달이 가능해집니다.
이는 현재 사용중인 WAL 파일이 채워지는 동안 Main Server와 Standby Server 간의 Data Lag(지연)이 발생할 수 있음을 의미하며, 장애발생 시 Replication내역이 최대 WAL 파일 크기만큼 소실될 수 있음을 의미하기도 합니다.
📢 Data Lag를 줄이기 위해
archive_timeout 파라미터를 통해 WAL 파일을 주기적으로 전환(Switch)하는 시간을 지정하면 WAL 파일이 가득 차지 않아도 Archive를 발생시켜 Data Lag를 줄일 수 있습니다. 단, 너무 짧게 설정할 경우 Archive Directory 크기가 증가하므로 주의해야 합니다.File-based Log Shipping은 PostgreSQL 버전에 따라 Warm Standby와 Hot Standby로 구분할 수 있으며, 두 방식의 차이점은 Standby Server에 접속하여 읽기(Read-Only, SELECT) 작업을 수행할 수 있는지 여부입니다.
Warm Standby
Warm Standby는 PostgreSQL 8.3 버전에서 도입된 File-based Log Shipping 방식입니다. Warm Standby 방식에서는 Standby Server에 사용자가 연결할 수 없으며, 읽기(SELECT) 작업도 불가능합니다. Warm Standby와 관련된 파라미터는 아래와 같습니다.
구분 | 파라미터 |
Main Server | wal_level, archive_mode, archive_command, archive_timeout, max_wal_senders |
Standby Server | standby_mode, restore_command, archive_cleanup_command, trigger_file |
Hot Standby
Hot Standby는 PostgreSQL 9.0 버전에서 도입된 File-based Log Shipping 방식으로 Replication 방식은 Warm Standby와 동일하지만, Standby Server에 사용자가 연결할 수 있고, 읽기(Read-Only, SELECT) 작업이 가능합니다. Hot Standby와 관련된 파라미터는 아래와 같습니다.
구분 | 파라미터 |
Main Server | wal_level, archive_mode, archive_command, archive_timeout, max_wal_senders |
Standby Server | standby_mode, restore_command, hot_standby, archive_cleanup_command, trigger_file |
📢 Warm과 Hot Standby의 차이점은 Standby Server로의 접속가능 여부라고 할 수 있습니다. 이런 이유로, Warm Standby는 현재 거의 사용되지 않고 있습니다.
File-based Log Shipping 장·단점
File-based Log Shipping 방식의 장·단점은 다음과 같습니다.
장점 | 단점 |
• 다른 Replication 방식에 비해 구성이 간단
• archive_command 파라미터를 이용하여 Standby Server로 WAL 파일을 전송하기 쉬움
• 다중 Standby Server 구성 가능 | • Major 버전과 Bit가 모두 동일해야 구성 가능
• WAL 파일이 가득 차거나(16MB), archive_timeout에 의해 Switch 된 WAL 파일을 전송하므로 Main Server 장애 시 Switch 되지 않은 WAL 파일에 대한 Data 유실 가능성 존재
• Standby Server와의 통신이 끊겨 WAL 파일이 전송되지 못한 채 삭제된 경우, WAL 파일 부재로 Replication은 종료되며, Standby Server를 재구성해야 함
• Warm Standby 구성 시 Standby Server에 접속 및 SELECT 불가 (Hot Standby는 해당사항 없음) |
Streaming Replication
PostgreSQL 9.0 버전부터 등장한 Streaming Replication은 Physical Replication 종류 중 하나로, Main Server의 WAL 파일이 채워질 때까지 기다리지 않고 WAL Record를 실시간으로 Streaming 하는 방식을 말합니다.
파일이 아닌 WAL Record를 전달하기 위해서, Main Server에는 WAL Sender, Standby Server에는 WAL Receiver라는 전담 프로세스가 필요하며, 이 프로세스들이 Server 간의 동기화를 수행합니다.
해당 방식은 Transaction Commit 후 Standby Server에 적용되기까지 약간의 지연(대략 1s 미만)이 발생할 수 있지만, File-based Log Shipping 방식에 비하면 현저히 적습니다.
만약 아직 동기화되지 않은 WAL Record가 포함된 WAL 파일이 삭제될 경우, 더 이상 동기화를 진행할 수 없으므로 Replication을 재구성해야만 합니다. 이러한 사태를 미연에 방지하기 위해
wal_keep_size 파라미터로 WAL 파일의 개수를 지정하면, 동기화 전 WAL 파일이 삭제되는 상황을 예방할 수 있습니다. 또한, WAL 파일이 삭제되기 전에 별도의 공간에 보관하여 restore_command 파라미터를 사용하여 복구할 수 있습니다. Streaming Replication과 관련된 파라미터는 아래와 같습니다.구분 | 파라미터 |
Main Server | wal_level, wal_keep_size(wal_keep_segements), max_wal_senders |
Standby Server | hot_standby, primary_conninfo, restore_command |
📢
wal_keep_size는 PostgreSQL 13 버전부터 사용되며, 이전 버전의 경우 wal_keep_segments를 사용합니다.Streaming Replication 장·단점
Streaming Replication 방식의 장·단점은 다음과 같습니다.
장점
- 다른 Replication 방식들에 비해 구성이 간단
- File-based Log Shipping 방식에 비해 최신의 상태로 Standby Server를 유지 가능
- WAL Record를 전달받는 방식으로, WAL 파일의 Switch 여부와 상관없이 Replication 가능
단점
- 아직 동기화되지 않은 WAL Record가 포함된 WAL 파일이 삭제된 경우, WAL Record의 부재로 Replication이 종료되며, Standby Server의 재구성 필요
- Main Server를 계속 Streaming 해야 하므로 Main Server에 영향을 미칠 수 있음
Physical Replication 한계점
Physical Replication(File-Based Log Shipping, Streaming Replication)은 구성이 비교적 간단하다는 장점이 있지만, 아래와 같은 공통적인 제약사항이 존재합니다.
- Database의 일부만 Replication 불가능(특정 Database나 Table에 대해서만 Replication 불가)
- Standby Server에서는 Write 작업 불가능
- PostgreSQL의 Major 버전이 다르다면 Replication 불가능
- PostgreSQL이 설치된 Platform이 다르다면 Replication 불가능
위의 제약사항을 극복하기 위해 다음으로 설명할 Logical Replication이 도입되었습니다.
Logical Replication
마지막으로 소개할 Logical Replication은 PostgreSQL 10 버전부터 사용 가능하며, File System Replication이나 WAL Log Shipping 방식의 한계를 극복하기 위한 목적으로 도입되었습니다.
Logical Replication은 하나의 게시자(Publisher)와 하나 이상의 구독자(Subscriber)로 구성됩니다. 구독자는 자신이 구독(Subscription) 중인 게시자의 Data를 가져와 이를 다시 게시(re-publish), 게시자가 될 수 있으며 추가적인 구독자를 만들 수 있습니다.
구독과 게시 간의 Replication은 복제 ID(Replication Identify)를 기반으로 수행되며, 복제 ID는 기본키(Primary Key) 또는 고유키(Unique Key)가 될 수 있습니다. 기본키와 고유키가 존재하지 않는다면,
REPLICA IDENTITY FULL 옵션으로 Table 속성을 변경하여 사용할 수 있습니다. 하지만, 이 방법은 Table 변경사항이 있을 때마다 전체 Table을 복제하므로 자주 업데이트되는 대용량 Table에 대해서는 비효율적이며 자원을 많이 소모할 수 있습니다.📢 기본키와 고유키가 없어도 Logical Replication이 가능합니다. 하지만 비효율성과 Disk 사용량이 증가하며, 데이터 무결성 또한 보장할 수 없기 때문에 기본키나 고유키를 설정할 것을 권장합니다.
Logical Replication 사용사례
- 여러 Database를 단일 Database로 통합
- 서로 다른 Major 버전 간의 복제
Logical Replication 장·단점
Logical Replication 방식의 장·단점은 다음과 같습니다.
장점
- 특정 Database 또는 Table만 Replication 가능
- Standby Server에서 DDL, DML 등의 쓰기 작업 가능
- 서로 다른 Major 버전, Platform 간 Replication 가능 (Migration과 Upgrade에 활용)
- 구독자가 게시자가 되는 다중 형태 구성 가능
- 구독에 대한 DML 유형(INSERT, UPDATE, DELETE, TRUNCATE)을 선택적으로 사용가능
- 구독(Subscription)에는 게시(Publication) 보다 많은 Column 정의가 가능하며 순서에 영향을 받지 않음. 단, Replication 되는 Column의 Type과 이름은 동일해야 함
단점
- Table은 구독(Publication)과 게시(Subscription)에서 동일한 이름을 사용해야 함
- Table에는 기본키(Primary Key) 또는 고유키(Unique Key)가 존재해야 함
- 양방향 Replication 불가능
- Sequence, Large Objects, Materialized Views, Partition Root Table, Foreign Table 미지원
- DML 작업에서만 지원되며, DDL은 직접 수행
- Replication 된 Data가 제약 조건과 충돌하는 경우 Replication이 중지되며 충돌 원인이 해결되어야 Replication 재개가 가능
그 외 Replication
앞서 설명한 Replication 방식 외에도 다음과 같은 다양한 방식이 존재합니다.
- Trigger-Based Primary-Standby Replication
- SQL-Based Replication Middleware
- Asynchronous Multimaster Replication
- Synchronous Multimaster Replication
또한, PostgreSQL에서 기본으로 제공하고 있는 Repliation 기능 외에 Replication을 지원하는 상용솔루션들이 다양합니다.(아래표 참조)
마치며
• 고가용성을 목표로 Sreaming Replication과 Log Shipping Replication을 동시에 사용 • 특정 Table에 대한 감사목적으로 Logical Replication 활용 • Version Upgrade를 위한 Data Migration을 Logical Reaplication으로 대체
위 예시처럼, Replication 사용을 고민한다면, 업무 요구 사항 및 제약뿐만 아니라, 개별 Replication 기술의 한계까지 이해해야 적합한 솔루션을 찾을 수 있습니다. 그리고 본 문서에서는 이를 위해 PostgreSQL이 제공하는 Replication기술들을 분류하고 그 특징에 대해 알아보았습니다.
다음 시리즈에서는 Physical Replication(Log Shipping, Streaming)과 Logical Replication을 구성하는 방법에 대해서 알아보겠습니다.
함께 보면 좋은 아티클
