설문조사
PostgreSQL/PPAS 관련 듣고 싶은 교육은


Powered by EnterpriseDB
총 게시물 59건, 최근 0 건
   

LOG shipping & Streaming Replication

글쓴이 : 처음부터 날짜 : 2014-12-16 (화) 23:52 조회 : 2784
익히 알고 있는 것이겠지만, 새로 접하는 분을 위하여 간단하게 정리합니다.

일단, 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와 큰 차이가 보이질 않습니다.




PGAdmin 2014-12-19 (금) 00:10
Streaming Replication (SR)의 동작 방식은 설명하신 내용과 다릅니다.
http://www.postgresql.org/docs/current/static/warm-standby.html#STREAMING-REPLICATION

위 매뉴얼을 보시더라도 SR은 WAL record를 stream 한다고 되어 있습니다.
설명해주신 로그 쉬핑을 Warm Standby라 불렀고, PG가 9.0 이 나오면서 Hot Standby 방식의 SR 이 지원되기 시작하였습니다.

좀더 부연 설명을 드리자면, 이러한 데이터 리플리케이션 방식을 크게 Physical standby와 Logical standby 두가지로 구분할 수 있는데요,
Physical의 경우 마스터 서버와 물리적으로 같다해서 physical standby라고 부릅니다. 이를 구현하는 방식은 마스터의 트랜잭션 로그를 스탠바이로 보내고 이를 '복구'의 방식으로 변경 데이터를 반영합니다.
반면에 Logical의 경우는 트랜잭션 로그 형식으로 전송은 되지만 이를 적용할 때 SQL로 변경하여 SQL을 실행하여 적용하는 방법을 사용합니다.

설명주신 내용은 copy로 raw 데이터를 전송한다고 하셨는데, 이는 CDC (change data capture) 솔루션의 방식에 더 가까워 보이네요.

SR은 WAL 버퍼의 데이터가 WAL log file에 써지는 시점에 sender라는 프로세스가 스탠바이 서버의 receiver 프로세스로 전송하고 이를 복구하여 적용하는 방식의 physical standby 방식으로 동작합니다.
댓글주소
   

postgresdba.com