postgreSQL Replication 개념

WAL

 

PostgreSQL 에서 제공하는 복제 서버 구축 방식을 요약하면 다음과 같다.

1. 마스터 서버에서 발생하는 모든 작업을 로그로 만든다.
2. 이 로그를 스탠바이 서버들로 전달한다.
3. 스탠바이 서버들에서 받은 로그를 복원(재실행) 한다.

이렇게 하면 마스터 서버와 같은 스키마/데이터를 가지는 복제 서버가 탄생하게 된다. 이 때, 마스터 서버의 로그를 WAL(Write Ahead Log) 이라고 한다.

 

---

WAL 전달 방식

 

WAL 파일 자체를 스탠바이 서버로 전달(file copy)하면 Log-Shipping 방식이다.

WAL 파일 저장 여부와 관계 없이 로그의 내용을 스탠바이 서버로 직접 전달하면 Streaming 방식이 된다.

 

---

Log-Shipping(Physical Replication)

마스터 서버에서 지정된 WAL 파일의 크기를 다 채워야 스탠바이 서버로 전송이 일어나기 때문에, 그 시간 동안 마스터/스탠바이 서버의 데이터가 어긋나 있는 상태가 유지된다. 만약 이 때 마스터 서버에 장애가 발생한다면 WAL 파일을 다 채우지 못해서 전달되지 못한 로그는 유실될 수 밖에 없다.

장점 :

• 다른 Replication 방식에 비해 구성이 간단
• archive_command 파라미터를 이용하여 Standby Server 로 WAL 파일을 전송하기 쉬움
• 다중 Standby Server 구성 가능

단점 :

• Major 버전과 Bit 가 모두 동일해야 구성 가능
• WAL 파일이 가득차거나 archive_timeout 에 의해 Switch 된 WAL 파일을 전송하므로 Main Server 장애시 Switch 되지 않은 WAL 파일에 대한 Data 유실 가능성 존재
• Standby Server 와의 통신이 끊겨 WAL 파일이 전송되지 못한 채 삭제된 경우, WAL 파일 부재로 Replication 은 종료되며, Standby Server 를 재구성해야 함
• Warm Standby 구성 시 Standby Server 에 접속 및 SELECT 불가 (Hot Standby 는 해당사항 없음)

Warm Standby

Standby 서버에 사용자가 연결할 수 없으며 읽기(SELECT) 작업도 불가능하다.

Hot Standby

Standby 서버에 사용자가 연결할 수 있고, 읽기(Read-Only, SELECT) 작업이 가능하다.

 

Warm vs Hot

Warm 과 Hot 의 차이점은 Standby 서버로의 접속 가능 여부라고 할 수 있다. 이런 이유로 Warm Standby 는 현재 거의 사용되고 있지 않는다.

 

---

Streaming(Physical Replication)

두 서버간의 네트워크에 문제가 없다는 가정하에, 거의 실시간으로 동작한다고 봐도 무방하다.(1초 미만의 작은 지연 발생) 따라서 데이터 유실에 대한 걱정을 그만큼 덜 수 있으므로 Streaming 방식을 선택하지 않을 이유가 없다.

그러나 Streaming 방식의 경우, 만약 스탠바이 서버에 긴 장애가 발생한 경우 문제가 생길 수 있다. 이는 마스터 서버에서 WAL 파일을 재활용하기 때문이다. 만약 스탠바이 서버에 장애가 길어져서, 그동안 마스터 서버가 가장 오래된 WAL 파일을 덮어써버린다면, 스탠바이 서버가 복구된 이후에도 유실된 WAL 내용을 복원할 수 있는 방법이 없다.

마스터 서버 postgresql.conf 설정 파일 안의 wal_keep_segments 옵션에 따라 저장하고 있는 WAL 파일의 최대 갯수가 정해진다.

만약 wal_keep_segments 값이 32 라면, 스탠바이 서버에 장애가 발생한 순간부터, 마스터 서버에서 33번째 WAL 을 쓰기 시작한다면 1번째 파일은 유실된다.

만약 유실되는 데이터가 생길 경우, 다시 데이터를 동기화 할 방법은 스탠바이 서버를 처음부터 다시 구축하는 방법 밖에는 없다. 따라서 데이터의 빠른 동기화를 위해서 Streaming 방식을 사용하더라도, 이와 같은 문제를 피하기 위해 Log-Shipping 방식을 적용해 놓는 것이 좋다. (스탠바이 서버의 장애가 길어지더라도 그동안 WAL 파일의 복사는 계속 되므로 장애 복구 후 WAL 복원이 가능)

장점 :

• 다른 Replication 방식들에 비해 구성이 간단
• Log Shipping 방식에 비해 최신의 상태로 Standby Server 를 유지 가능
• WAL Record 를 전달받는 방식으로 WAL 파일의 Switch 여부와 상관없이 Replication 가능

단점 :

• 아직 동기화되지 않은 WAL Record 가 포함된 WAL 파일이 삭제된 경우, WAL Record 의 부재로 Replication 이 종료되며 Standby Server 의 재구성 필요
• Main Server 를 계속 Streaming 해야하므로 Main Server 에 영향을 미칠 수 있음

 

---

Physical Replication 한계점

구성이 비교적 간단하다는 장점이 있지만, 아래와 같은 공통적인 제약사항이 존재한다.

• Database 일부만 Replication 불가능 (특정 Database 나 Table 에 대해서만 Replication 불가)
• Standby Server 에서는 Write 작업 불가능
• PostgreSQL 의 Major 버전이 다르다면 Replicaion 불가능
• PostgreSQL 이 설치된 Platform 이 다르다면 Replication 불가능

위의 제약사항을 극복하기 위해 Logical Replication 이 도입되었다.

 

---

Logical Replication

하나의 게시자(Publisher) 와 하나 이상의 구독자(Subscriber) 로 구성된다. 구독자는 자신이 구독중인 게시자의 Data 를 가져와 이를 다시 게시, 게시자가 될 수 있으며 추가적인 구독자를 만들 수 있다.

구독과 게시간의 Replication 은 복제ID 를 기반으로 수행되며, 복제 ID 는 기본키 또는 고유키가 사용될 수 있다.

기본키와 고유키가 존재하지 않는다면 REPLICA IDENTITY FULL 옵션으로 테이블 속성을 변경하여 사용할 수 있다. 하지만 이 방법은 테이블 변경사항이 있을 때마다 전체 테이블을 복제하므로 자주 업데이트되는 대용량 테이블에 대해서는 비효율적이며 자원을 많이 소모할 수 있다.

기본키와 고유키가 없어도 Logical Replication 이 가능하다. 하지만 비효율성과 Disk 사용량이 증가하며, 데이터 무결성 또한 보장할 수 없기 때문에 기본키나 고유키를 설정할 것을 권장한다.

장점 :

• 특정 database 또는 테이블만 Replication 가능
• Standby Server 에서 DDL, DML 등의 쓰기 작업 가능
• 서로 다른 Major 버전, Platform 간 Replication 가능 (Migration 과 Upgrade 에 활용)
• 구독자가 게시자가 되는 다중 형태 구성 가능
• 구독에 대한 DML 유형 (INSERT, UPDATE, DELETE, TRUNCATE)을 선택적으로 사용 가능
• 구독에는 게시보다 많은 Column 정의가 가능하며 순서에 영향을 받지 않는다. 단 Replication 되는 Column 의 Type 과 이름은 동일해야함

단점 :

• 테이블은 구독과 게시에서 동일한 이름을 사용해야 한다.
• 테이블에는 기본키 또는 고유키가 존재해야 한다.
• 양방향 Replication 불가능
• Sequence, Large Objects, Materialized Views, Partition Root Table, Foreign Table 미지원
• DML 작업에서만 지원되며 DDL 은 직접 수행
• Replication 된 data 가 제약 조건과 충돌하는 경우 Replication 이 중지되며 충돌 원인이 해결되어야 Replication 재개가 가능

 

---

그 외 Replication

• Trigger-Based Primary-Standby Replication
• SQL-Based Replication Middleware
• Asynchronous Multimaster Replication
• Synchronous Multimaster Replication
• 등등…

---

마스터 서버에 장애가 발생했을 때 어떻게 스탠바이 서버를 써먹을 수 있는지 (failover)

마스터 서버에 발생했던 장애가 복구된 이후 어떻게 최초의 상황으로 돌아갈 수 있는지(failback)

PostgreSQL 자체적으로는 기본적인 기능만 제공하고 있다. 고급 기능을 더 편리하게 이용하고 싶다면 pgpool-ll 나 slony-l 같은 도구를 리서치하는 것도 좋은 방법이다.

이외의 각종 3rd party 도구들 비교 자료 : https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

Replication, Clustering, and Connection Pooling - PostgreSQL wiki

 

---

Failover

스탠바이 서버를 운영 서버로 전환하는 방법은 두 가지가 있는데 하나는 pg_ctl promote 명령어를 사용하는 방법이고, 또 하나는 recovery.conf 파일에 trigger_file 옵션을 이용하는 방법이다. trigger_file 에 경로를 등록해 놓으면 해당 경로에 파일이 생성되었을 때 (touch 등으로) 스탠바이 서버가 새로운 마스터 서버로 승격된다.

스탠바이 서버를 승격시킬 때는 기존 마스터 서버가 확실하게 다운된 상태인지 확인해야한다.

만약 마스터 서버가 살아있는 상태에서 스탠바이 서버를 승격 시킬 경우, 데이터 손실 등의 예상치 못한 문제가 발생 할 수 있으니 주의가 필요하다.

 

---

Auto Failover

만약 자동으로 failover 를 하고 싶다면 다른 도구나 방법을 강구해야 한다. 위에서 소개한 도구들에서 자동 failover 를 지원하는 듯 하다.

 

---

Failover 후 운영

스탠바이 서버를 승격시키고 난 후에는, 기존 마스터 서버의 장애가 복구되고 failback 되기 전까지 마스터 서버 하나로 운영해야하는 상황이 발생한다.

기존 마스터 서버가 어떤 이유로 장애가 났는지 예측할 수 없기 때문에 빠른 failback 을 장담할 수 없고 그동안 위험한 상황이 발생할 수 있다.

이런 상황을 대비해서 미리 제 3의 머신을 준비해 놓거나, 혹은 애초에 2개의 복제 서버를 만들어 놓는 것도 방법이 될 수 있다. (위에서 소개한 도구들에서 멀티 혹은 Cascading 스탠바이를 지원하는 것으로 보인다)

 

---

Failback

기본적으로 Failback 을 위해서 특별한 기능이 제공되지 않는다. 따라서 다음 단계를 거쳐야 한다.

1. 마스터 서버의 장애가 복구되면 이 서버를 스탠바이 서버로 구축한다.
2. 새 마스터 서버(기존 스탠바이 서버)를 강제로 다운 시킨다.
3. 새로 구축된 스탠바이 서버를 다시 마스터 서버로 승격시킨다.
4. 스탠바이 서버를 새로 구축한다.

더 쉽게 Failback 을 할 수 있는 방법에 대해 알아봐야겠다.

 

---

PGPOOL-II

PostgerSQL 서버와 PostgreSQL 데이터베이스 클라이언트 사이에 위치하는 프록시 소프트웨어이다.

제공기능은 다음과 같다.

• Connection Pooling
• Load Balancing
• Automated fail over
• Replication
• Limiting Exceeding Connections

Connection Pooling

Pgpool-II 는 PostgreSQL 서버와의 연결을 유지하고 같은 등록 정보 (예 : 사용자 이름, 데이터베이스, 프로토콜 버전) 를 가진 새로운 연결이 들어올 때마다 이를 다시 사용한다. 연결 오버 헤드를 줄이고 시스템의 전체 처리량을 향상시킨다.

Load Balancing

데이터베이스가 복제되면 모든 서버에서 SELECT 쿼리를 수행하면 동일한 결과가 반환된다. Pgpool-II 는 각 PostgreSQL 서버의 부하를 줄이기 위해 복제 기능을 이용한다.

사용 가능한 서버에 SELECT 쿼리를 배포하여 시스템의 전체 처리량을 향상시킨다. 이상적인 시나리오에서는 읽기 성능이 PostgreSQL 서버의 수에 비례하여 향상될 수 있다. 부하 분산은 많은 읽기 전용 쿼리를 동시에 많은 사용자가 실행하는 시나리오에서 가장 효과적이다.

Automated fail over

데이터베이스 서버 중 하나가 다운되거나 복구 할 수 없게 되면 Pgpool-II 은 데이터베이스 서버를 분리하고 나머지 데이터베이스 서버를 사용하여 작업을 계속한다. 시간 초과 및 재시도를 포함한 자동화 된 장애 조치를 도와주는 정교한 기능이 있다.

Replication

Pgpool-II 은 여러 PostgreSQL 서버를 관리할 수 있다. 복제 기능을 활성화하면 두 개 이상의 PostgreSQL 클러스터에서 실시간 백업을 생성 할 수 있으므로 해당 클러스터 중 하나에서 장애가 발생해도 중단없이 서비스를 계속할 수 있다.

Pgpool-II 은 기본 복제기능이 있다. 그러나 사용자는 PostgreSQL 자체적인 스트리밍 복제를 포함한 외부 솔루션의 복제 기능을 사용할 수 있다.

Limiting Exceeding Connections

PostgreSQL 과의 동시 접속의 최대 세션에 제한이 있어 최대 세션에 이르면 신규 접속은 거부된다.

그러나 이 최대 연결 수를 늘리면 자원 소비가 증가하고 전체 시스템 성능에 부정적인 영향을 준다.

Pgpool-II 에는 최대 연결 수에 제한이 발생해도 커넥션 풀에 의한 접속 오류를 바환하는 대신 큐에 쌓아두고 세션을 대기시킨다.

 

---

참고 링크

 

https://berasix.tistory.com/entry/PostgreSQL-%EC%9D%B4%EC%A4%91%ED%99%94-1-DB%EC%9D%B4%EC%A4%91%ED%99%94%EC%99%80-PostgreSQL-Cluster

[PostgreSQL 이중화] #1. DB이중화와 PostgreSQL Cluster

https://medium.com/@qodot/postgresql-replication-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-dfd481c4fb04

PostgreSQL Replication 구축하기

https://www.postgresql.org/docs/current/runtime-config-replication.html

20.6. Replication

https://blog.ex-em.com/1781

DB 인사이드 | PostgreSQL Replication - 종류