익히 알고 있는 것이겠지만, 새로 접하는 분을 위하여 간단하게 정리합니다.
일단, Master-Slave 구성방식을 지원하는 Postgresql의 기본 Method는 두가지입니다.
1. Log Shipping
- 해당 내용을 설명하기 전에 먼저, 단순 백업 & 복구과정을 살펴보겠습니다.
* 일단 단일 서버에서 Database 가 Crash되었을 때
* Database 파일 (postgresql에서는 /data/base 디렉토리 내용)과 지금까지 수행했던
Transaction Record 파일인 WAL 파일들만 있으며, Roll-Forward를 통해 복구합니다.
* ORACLE Archive + REDO log에 해당하는 WAL 목록과 초기 database 파일만 있으면
어디서든 복구가 가능하다는 이야기가 됩니다.
* Log (File) Shipping은 위 내용을 기반으로 복구 절차를 수행하는 것입니다.
- 일단 두개의 DB 서버를 설정하고,
- Master에서 초기 데이터베이스를 Slave로 Import 해 놓습니다. (pg_basebackup 사용. etc..)
- 여기까지 수행하면, 일단 두개의 Database는 같은 자료를 가지고 있습니다. 맞죠?
- 그 다음, postgres.conf에 있는 archive_mode 를 archive 상태로 변경하고,
- archive_command 에 rsync (복사명령어)로 slave 서버에 archive를 보내도록 설정합니다.
- slave server는 shutdown 해 놓습니다.
- 여기까지가 기본 설정 끝입니다.
- 그 다음 Master에서 자료가 들어오기 시작하면, 데이터 베이스 파일도 변경된고,
각각의 Transaction은 WAL 파일에 차곡차곡 쌓입니다.
- 일정 주기가 되면 해당 WAL 파일은 rsync에 의해서 두번째 서버로 넘어갑니다.
- 여기까지가 기본 운영 상태입니다.
- 여기서 Master 가 Crash 되었다고 합시다. (에러 발생) 운영자는 이를 알아채고
- Slave에 recovery.conf 파일을 설정하고 기동합니다.
- Slave는 초기 데이터베이스 파일과 현재까지 발생한 모든 Transaction record정보인 WAL
로그를 확인하고, 초기 데이터베이스 파일에 하나씩 Transaction 변경 정보를 반영합니다.
- 모든 Trasnsaction 반영이 끝나면, 정상적으로 database 가 Open 됩니다.
- 즉. 단순한 백업 & 복구를 다른 서버에서 하겠다는 의미만 있습니다.
- 여기서 재미있는 내용은, Master->Slave로 Archive 파일(WAL파일이지만...) 옮기는 것은
마음대로 라는 점. GFS2를 써도 되고, rsync를 써도 되고, NFS를 써도 되고
- 단 archive_command가 Fail 나면 좋을 것이 없으니, NFS를 사용하는 경우, 이중화를 고려
- 단점이 있습니다. WAL 파일이 건너오는 시점은 Transaction 단위가 아니라는 점입니다
즉, 16M에 해당는 파일을 Transaction마다 archive할 수는 없습니다.
- 보통의 경우는 하나의 WAL파일안에 여러개의 transaction이 기록되어 16M 꽉 차면
- log_switch 가 발생하고, 이 시점에서 archiving이 발생합니다.
- 즉 이전 log_switch 발생 시점부터 crash 된 시점까지 발생한 transaction은 Slave에서
복구할 수 없습니다.
2. Streaming Replication
- Streaming Replication은 살짝 다릅니다.
- 구조적으로 WAL(archive)를 이용하지 않고, Transaction 정보 자체를 건별로 이용합니다.
- Master-Slave간에 TCP 연결을 하고, Master CUD발생시, COPY명령어로 Raw데이터 전송
- 동기방식/비동기 방식이 있는데, 차이는 간단합니다. Slave로 보내어 지는 COPY명령어의
결과를 기다릴지 말지 입니다. 기다린다는 의미는 하나의 Transaction으로 묶인다는 의미
입니다.
- 이는 Maser/Slave간에 동일한 자료를 같은 시간에 유지하기 위해서는 필수 항목입니다만,
- 모든 Transaction이 두개의 서버에서 모두 발생하기 때문에처리시간 길어지는 단점이 존재합니다.
- 비동기 방식은 Slave에서 자료를 받아서 즉시 처리하지만, 같은 Transaction으로 묶이지는
않아, 짧은 시간안에서는 Master/Slave 조회 결과가 다르게 보일 수 있습니다.
- 하지만, 이 time-lag는 매우 짧아, 실제 시스템 요구 조건에 따라서는 무시될 수 있는 내용입니다.
- 또한 성능도 Single Instance와 큰 차이가 보이질 않습니다.
