postgreSQL의 고가용성을 위한 방법

database 에서는 고가용성을 위해 메인으로 운영되는 db 이외에 백업 본으로 replica db 가 연결된 상태로 운영되는 경우가 많다. replication  이라고 하는데, primary-standby 구조라고 하기도 하고 active-standby, master-slave 등으로 다양하게 부른다. 1대의 read/write 가 가능한 primary 노드가 있고, 그 이외에 standby 노드 들이 해당 primary의 데이터를 계속 동기화 시키면서 복제 해두는 방식으로 운영 된다. 

 

이렇게 replica  를 나누는 이유는, primary 노드에 장애가 발생 했을때 빠르게 standby 노드를 이용해 복구 시킬 수 있고, standby 노드는 read 용으로 사용할 수 있기 때문에 부하를 분산 시키는 용으로도 사용 된다. 

 

replication 동기화 방법

크게 physical replication 과 logical replication 으로 구분 가능하다. 

physical replication 은 WAL(Write-Ahead Log) 를 전달 하는 방식으로 실제 파일 단위로 동기화가 이루어진다. 반면에 logical replication 은 SQL statement 단위나 데이터 베이스 테이블 단위로 동기화를 할 수 있다. 

 

WAL(Write-Ahead Log) [참고] 란 실제로 데이터를 수정하는 작업을 진행하기 전에 log 형태로 파일에 작성 하는 방법을 의미 한다. 해당 방식은 postgreSQL뿐만 아니라 여러 데이터베이스나, 처리 시스템에서 많이 쓰이는 방식이다. postgreSQL 에서는 주로 이 WAL 을 통해 데이터를 복구 하고, standby replica 노드를 구축하는데 사용한다. 

 

physical replication

 

1) file-based log shipping 

- primary 노드 에서는 사용자가 데이터 수정요청이 들어온 트랜잭션 로그 들을 WAL 로 남기게 되고, standby 에서는 해당 WAL 을 받아와서 읽는 방식이다.  근데 실시간으로 전달 하는 것은 아니고, WAL 파일이 특정 크기 가 만족 되면 전달 된다. 그러다 보니 WAL 가 다 채워지는 동안의 싱크가 안맞는 상황이 생기기도 하다. 그리고 WAL 파일을 standby 에서 계속 안가져 가면 WAL 파일이 언젠가는 새로운 파일로 덮어 씌워 져서 아예 standby 에서 데이터가 소실 되는 상황도 발생할 수 있다. 

 

2) streaming 

- file-based 에서의 데이터 유실 문제를 해결 하기 위해 9.0 버전 에서 부터 등장한 replication 방법이다. 아까 file-based 에서는 WAL 파일이 특정 크기가 될 때까지 기다렸는데, streaming 방식에서는 기다리지 않고 실시간으로 primary node 의 WAL sender 에서 전송하게 된다. 그렇기 때문에 file-based에 비해 동기화 지연률이 많이 낮아지게 된다. 

 

ref. https://velog.io/@ieieie0419/PostgreSQL4-PostgreSQL-Replication

logical replication

10버전 부터 사용 가능한 방법으로, 위의 physical replication 의 한계를 극복하기 위해서 나왔다. WAL 파일을 이용하는 physical replication 과 다르게, 데이터베이스의 테이블 단위, 로우 단위로 replication 단위를 정할 수 있다. logical 에서 쓰이는 방법은 physical 과 비슷하게 WAL 을 만들어두기는 하지만, 트랜잭션을 SQL 단위로 변환 해서 저장해 둔다. 

 

 

replication 동기화 방식

postgresql 에서 replication 의 동기화를 맺을 때 또 나뉘어 질 수 있는게 sync 나 async 냐로 구분될 수 있다. 

asyncronous

async 방식은 primary 노드에 변경사항이 발생 했을 때, standby 는 primary 에 먼저 commit 이 반영된 이후에 반영되게 된다. 그러다 보니 primary 와 standby 간의 데이터 싱크가 조금씩 딜레이가 생길 수 있다. 하지만 ...  primary 가 standby 적용 상태에 영향을 받지 않으니 성능이 안좋아지거나 하는 문제는 거의 없다. 

 

synchrounous

aync 와 다르게 standby 에 commit 이 완료 되어야 primary commit 이 끝나는 방식이다. 매번 standby 까지 신경써야 하니 primary 에 데이터 수정에 오버헤드가 생길 수 있다. 하지만, 데이터 동기화 지연은 생기지 않기 때문에 데이터가 유실될 일은 async보다 훨씬 낮다. 

 

ref.

https://dspace.lib.uom.gr/bitstream/2159/29723/1/VougiouklisEvangelosMsc2023.pdf 

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

https://www.cybertec-postgresql.com/en/services/postgresql-replication/synchronous-asynchronous-replication/

Synchronous and asynchronous replication