[PostgreSQL] Streaming Replication / Logical Replication

 

	Streaming Replication	Logical Replication
Replication 방식	- Master DB의 WAL에 기록된 내용을 실시간으로 Slave DB에게 전달 - WAL Sender, WAL Receiver라는 프로세스들이 두 서버간의 동기화를 수행 - Config 파일로 설정	- 주 서버의 WAL로 부터 데이터 변경 가능 stream을 만들어서 다른 서버로 복제 시키는 방식 - 테이블 단위로 replication 가능 - master나 slave로 구분해서 디자인된게 아니라 양방향으로 스트림 될 수 있음 (Target과 Source) - 쿼리 형태로 Replication 설정
Replication 설정 확인	- 프로세스 확인 시 Master DB에는 walsender, Standby DB에는 Walreceiver가 떠있음  - PostgreSQL에 접속 > Master DB에서 "select * from pg_stat_replication;", Standby DB에서 "select * from pg_stat_wal_receiver;"로 조회해 구성/운영 상태 확인	- 프로세스 확인 시 Source 쪽에는 logical replicaiton worker for publication 프로세스가 떠있고 Target 쪽에는 logical replication worker for subscription이 떠있음 - postgreSQL에 접속 > \dRP+ "." : logical replication 되고 있는 테이블 확인
장애복구	- master의 archive 파일을 slave의 pg_wal 쪽으로 가져오면은 재기동 됐을 때 sync 됨 - 장애가 많이 길어져 master 서버가 가장 오래된 WAL 파일을 덮어써버리면 유실된 WAL 내용을 복원할 수 있는 방법은 없 - pg_basebackup 명령어를 이용해 디렉터리를 통째로 복제/복원	- sync가 깨졌을 경우 쿼리문으로 sync를 다시 해줘야함 (target 쪽의 데이터를 Truncate로 지우고 다시 가져와야함) - pg_dump 사용 : 특정 table이나 DDL dump에 주로 사용되는 백업 *** -F 옵션 : 덤프받을 파일의 타입을 설정       p : plain으로 텍스트 파일로 출력 (vi로 편집 가능)       c : custom으로 적절한 커스터 아카이브로 출력을 하며 기본적인 압축도 해줌       t : tar 아카이브로 출력
관련 파라미터	- max_wal_senders : 스트리밍 기반의 백업 클라이언트로부터 동시 연결 최대 수  - wal_level : WAL에 기록되는 정보의 양 (minimal < archive < replica < logica ) - wal_keep_segments : 저장 가능한 WAL 파일 최대갯수	- max_worker_processes : 시스템이 지원할 수 있는 최대 백그라운드 프로세스 - max_logical_replication_workers : logical replication worker processes의 최대값(default는 4) - max_sync_worker_per_subscription : subscription : subscription 당 최대 동기화 worker 수

 

 

 

 

Streaming Replication

- WAL(Write Ahead Log)를 전달해서 Transcation Log Shipping 하는 Replication 방법 중 하나 
- WAL Log를 거의 실시간성으로 전달함으로써 별다른 지연없이 모든 DB가 동일한 값을 저장할 수 있게 하는 것

*** WAL(Write Ahead Log)란 ?
Database 변경 사항만을 저장한 Log를 말함

***Transaction Log Shipping을 이용한 Replication이란 ?
양쪽 DB의 원본이 동일하게 출발했다면 Primary DB Server에서 발생하는 변경사항을 기록한 WAL 파일들을 다른 DB server 순서에 맞춰 적용시키면 동일한 DB가 된다는 개념을 바탕으로 이루어짐

 

Streaming Replication을 위한 config 파일 수정 ( Master )

• Postgresql.conf 수정

- listen_address : 접속에 별다른 제한을 두지 않도록 설정

- WRITE AHEAD LOG 파트의 wal_level : hot_standby나 logical을 사용해야 replication이 가능한 WAL이 만들어짐

   (logical을 사용하면 Standby Server가 많아질 때 성능이 느려질 수 있다고함)

- REPLICATION 블록의 max_wal_senders (이 값이 0이면 Replication이 disabel 된다는 의미)

1. Standby Server의 수보다 커야함. 연결이 갑자기 끊긴 후 재접속 되는 경우 기존 연결이 타임아웃 될 때 까지 기존의 Connection Thread가 남아있기 때문에 Standby Sever 수보다 약간 더 크게 설정하는 것을 권장
2. WAL 전송을 위한 connection도 max_connections에 포함되기 때문에 max connections > max_wal_senders 여야함

• Replication Slot 생성
• pg_hba.conf 수정

 

Streaming Replication을 위한 config 파일 수정 ( Standby Server ) 

• Postgresql.conf 수정

- REPLICATION 블록의 Standby Server 

1. hot_standby : ON (Standby Server를 Read Only로 동작하게 설정)
2. hot_standby_feedback : ON (Replication 동작 시에 Query Conflict를 막는 목적)

• recovery.conf 만들기

 

 

 

Streaming Replication 방식 주의점

- Standby Server에 긴 장애가 발생할 경우 문제가 생길 수있음 

- 마스터 서버에서 WAL 파일을 재활용하기 때문에 스탠바이 서버에 장애가 길어져, 그동안 마스터 서버가 가장 오래된 WAL 파일을 덮어써버린다면, 스탠바이 서버가 복구된 이후에도 유실된 WAL 내용을 복원할 수 있는 방법이 없음

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

- 유실되는 데이터가 생길 경우, 다시 데이터를 동기화 할 방법은 스탠바이 서버를 처음부터 다시 구축하는 방법 밖에 없음

 

 

 

 

 

Logical Replication

- 변경된 데이터를 스트림으로 다른 서버로 보냄

- 테이블 단위로 리플리케이션 될 수도 있음

- master나 slave를 구분해서 디자인된게 아니라 양방향으로 스트림 될 수 있음