[PostgreSQL] WAL (Write Ahead Log ) 개념과 특징
Write-Ahead Log Shipping
Primary 서버의 WAL 내용을 Standby 서버로 옮겨 같은 상태를 유지하도록 하는 방식
Primary 서버의 장애가 발생하여 DBMS 가 중지되면 즉시 Standby 서버가 Primary 로 운영될 수 있다.
Standby 와 같은 대기 서버를 구축하려면, WAL 내용을 대기 서버로 전달하는 방식이 2가지가 있다.
- 파일 기반 로그 복사 ( 비동기 )
- Streaming Replication 방식 ( 동기,비동기 )
* 동기 - 데이터를 받는 방식에서 요청과 그 결과가 동시에 일어남, 결과가 주어질 때까지 다른 작업이 안되고 대기 상태 ( Sync )
비동기 - 동시에 일어나지 않아서, 바로 결과가 나타나지 않음, 하지만 복잡함 ( Async )
# 순서
1] Primary 서버에서 발생하는 모든 작업을 로그로 만든다.
2] 이 로그를 Standby 서버로 전달한다.
3] Standby 서버에서 받은 로그를 복원(재실행) 한다.
이렇게 하면 Primary 서버와 같은 스키마/데이터를 가지는 복제 서버가 탄생하게 된다.
이 때, Primary 서버의 로그를 WAL 라고 하며,
/var/lib/pgsql/~.x/data/pg_xlog 디렉토리에 쌓이게 된다.
이 디렉토리 안의 WAL 파일 자체를 전달(File Copy) 하면 Log-Shipping 방식
WAL 파일 저장 여부와 관계없이 로그의 내용을 직접 전달하면 Streaming 방식
# 전송방식
○ Log Shipping
Primary 서버에 발생하는 다 쓴 WAL 세그먼트 파일을 Standby 서버로 전송, Standby 서버는 복구 모드 전용(Readonly) 로 실행된다.
타 방식에 비해 작업비용이 적다
파일이 전송될 때의 전송량으로 네트워크 부하를 유발
단, Standby 서버에 지정된 WAL 세그먼트 파일의 크기를 다 채워야 전송이 일어나기 때문에,
그 시간동안 P/S 서버의 데이터가 어긋나 있는 상태가 유지된다.
이때, 장애 발생시 전달되지 못한 로그는 유실된다.
○ Streaming Replication - 비동기식
운영 중 발생하는 WAL 레코드를 순차적으로 Standby 서버로 전송
모든 Standby 서버에 장애가 발생해도 Primary 에 영향을 주지않고, 유실데이터가 발생하지 않는다.
○ Streaming Replication - 동기식
Failover 발생시에도 데이터 유실이 없기때문에 데이터 안정성이 매우 높다
직렬화된 트랜잭션 전달 작업(동기식) 으로 인해 성능 지연이 발생
# Streaming 방식 순서
1] 복제 전용 유저 생성
( Standby서버에서 Primary 에 접근할 Replication 전용 유저 생성 )
2] 유저에 대한 복제 권한 설정
3]
# Failover
시스템 에러 및 장애 발생으로 인한 손실 대비 기능
장애가 오면 미리 준비했던 다른 시스템으로 대체하여 운영 ( 이중화 )