27.3. 대기 서버 설정

PostgreSQL 서버를 대기 전용(standby) 서버로 운영 하고자 할 때, 이 값을 on으로 설정한다. 이렇게 하면, 복구할 WAL 파일을 모두 서버에 적용하고 나서, primary_conninfo 접속 정보로 운영 서버로 접속해서, 운영 서버에서 반영된 트랜잭션을 대기 서버에도 그대로 반영한다. 운영 서버와의 접속이 끊기면, 다시, restore_command 설정에 지정한 명령을 이용해서, 다시 대기 서버 쪽에 있는 WAL 파일들을 반영한다. 이런 작업을 반복해서, 운영 서버의 대기 서버로 운영할 수 있다.

운영 서버(primary server, master server)의 접속 정보. 이 문자열에 대한 자세한 설명은 32.1.1절을 참조하라. 여기서 사용할 수 있는 접속 환경은 표준 접속 방식과 동일하므로, 접속에 관련된 모든 환경 변수들(32.14절 참조)을 그대로 사용할 수 있다. 사용 우선 순위도 동일하다. 환경 변수가 지정되어 있고, 이 문자열에 지정되어 있지 않으면, 환경 변수 값을, 이 문자열로 지정했으면, 환경 변수를 무시하고, 이 문자열 값을 사용한다.

윗 standby_mode 설정값을 on으로 설정했다면, 이 접속 정보 문자열에는 최소한 운영 서버의 호스트 이름(또는 주소)는 지정해야한다. 포트가 기본값이라면, 생략해도 된다. 접속하려는 사용자가 계정은 운영 서버에 있어야하며, 해당 계정이 운영 서버로 접속해서 복제 작업을 할 수 있는 권한이 있어야한다. (26.2.5.1절 참조) 비밀번호 인증이 필요하다면, primary_conninfo 문자열에 지정하든가, 대기 서버의 ~/.pgpass 파일에 데이터베이스 이름을 replication으로 지정하고, 비밀번호를 등록해서 사용한다. primary_conninfo 설정값에는 접속할 데이터베이스 이름은 지정하지 않는다.

standby_mode 설정값이 off 상태면, 이 설정은 무시된다.

대기 상태가 끝났음을 알리는 파일 이름을 지정한다. 이 파일이 있으면, 대기 모드 상태를 끝내고, 독립 운영 서버로 실행환경을 바꾼다. 이 파일 이름을 지정하지 않으면, pg_ctl promote 명령으로 대기 모드를 끝낼 수 있다. standby_mode 설정값이 off 상태면, 이 설정은 무시된다.

기본적으로 대기 서버는 운영서버의 WAL 레코드를 최대한 빠르게 복원한다. 지연된 데이터 사본을 이용해 데이터 손실 에러를 다양한 방식으로 해결할 수 있다. recovery_min_apply_delay는 지정된 시간만큼 복구를 지연하고, 기본 시간 단위는 밀리 세컨드이다. 예를 들어 5min으로 지정하면, 대기 서버는 시스템 시각이 적어도 마스터 서버에 보고된 커밋 시간보다 5분 지났을 때, 각 트랜잭션 커밋을 리플레이 한다.

서버간 리플리케이션 지연이 recovery_min_apply_delay를 초과할 수도 있다. 지연 시간은 마스터 서버의 WAL timestamp와 현재 대기 서버의 시간 차이를 뜻한다. 네트워크나 지속적인 리플리케이션 설정으로 발생한 지연은 실제 대기 시간을 대폭 줄일 수 있다. 마스터 서버와 대기 서버간 시스템 시간이 동기화되지 않으면 예상보다 일찍 레코드를 복구할 수 있다. 서버간 시간 편차를 이용하는 것보다 recovery_min_apply_delay를 잘 설정하는 것이 더 유용하다. 마스터 서버와 대기 서버의 타임존은 다르게 설정해야 한다.

지연은 COMMIT이나 복원 시점에 WAL 레코드에서만 발생한다. 다른 레코드들은 지정한 지연 시간보다 일찍 리플레이 되는데, 복구 충돌이 더 자주 발생할 가능성도 있지만 MVCC에서는 큰 문제가 되지 않는다.

The delay occurs once the database in recovery has reached a consistent state, until the standby is promoted or triggered. After that the standby will end recovery without further waiting.

This parameter is intended for use with streaming replication deployments; however, if the parameter is specified it will be honored in all cases. hot_standby_feedback will be delayed by use of this feature which could lead to bloat on the master; use both together with care.