| PostgreSQL 9.3.5 문서 | ||||
|---|---|---|---|---|
| 이전 | 위로 | 장 25. 고가용성, 부하 분산, 복제 | 다음 | |
운영 서버에서 사용했던 로그를 대기 서버로 보내서 복제 기능을 구현하는 방법은 restore_command 설정값으로 지정한 명령으로 전달 된 파일을 자기 서버에 적용하고, 적용할 파일이 없으면, 그 명령을 계속 반복하는 식이다. 이 부분은 앞 장에서 구체적으로 설명했다. 여기서는 이 방법이 아닌, 8.4 이하 버전에서도 사용할 수 있는 데이터베이스 복구 기능을 이용해서 독자적인 로그 전달 복제 기법을 설명한다. 이렇게 하려면, 대기 모드로 실행하지 않고, 단순 복구 모드로 실행하도록 standby_mode 설정값을 off로 지정해야한다. pg_standby 모듈이 이 독자적인 복제 기능을 구현해 놓은 것이다.
이 방식에서 주의해야할 점은, 운영 서버에서 만들어진 WAL 파일은 그것들이 만들어지는 순서에 따라 그대로 대기 서버로 반영 되어야한다는 점이다. 또한 반영 하는 작업은 반드시 직렬화 되어서 한 번에 하나의 파일만 적용해야한다. 대기 서버에서 쿼리를 사용할 수 있게 설정 한다면, (Hot Standby) WAL 파일 적용 간격에 차이 때문에, 자료가 정확하게 운영 서버와 같지 않다는 점도 기억해야한다. 이 대기 서버로의 자료 반영 지연 현상을 줄이려면, archive_timeout 설정값을 짧게 하면 된다. 또한 이 방식으로 구현하면, 스트리밍 방식 복제를 사용할 수 없다는 점도 기억해야한다.
기본 작동 방식은 일반적인 로그 전달, 복구 방식과 같다. 트랜잭션 로그를 전달하는 방법은 WAL 레코드가 다 채워진, WAL 세그먼트 파일을 서로 전달하고, 받아서 사용하는 길 뿐이다. 운영 서버에서 만드는 순차적인 WAL 세그먼트 파일들이 대기 서버로 옮길 때, 누락되는 일이 없도록, 나중에 만들어진 파일이 이전에 만들어진 파일보다 먼저 대기 서버에 도착하는 일이 없도록 해야한다. 또한 다른 운영 서버에서 만든 WAL 세그먼트 파일과 섞여 구분이 안되는 일이 없도록 해야한다. 대기 기능만 구현하고자 한다면, WAL 파일 전달량은 그렇게 많지는 않다.
복제 기능을 독자적으로 구현하는 열쇠는 restore_command 설정값에 있다. 이 값은 대기 서버가 실행할 때 사용하는 recovery.conf 파일안에 restore_command 서버 환경 변수 매개변수 값으로 지정한다. 여기서 사용하는 명령은 서버가 처리해야하는 파일이 없으면, 0 아닌 값을 리턴해서, 복구 모드를 종료하고, 일반적인 정상 운영 서버로 실행 되도록 한다. 하지만, 복제용 대기 서버로 구축하려면, 이 명령은 원하는 파일이 없으면, 그 파일이 생길 때까지(운영 서버가 대기 서버로 보내줄 때까지) 기다리고 있다가, 생기면 다시 대기 서버가 복구 작업을 계속 할 수 있어야한다. 또한 .backup, .history이 운영 서버로부터 넘어 오면 그 파일은 무시하고, 0 아닌 값을 리턴하면서 이 명령을 끝내야한다. 이렇게 설명한 모든 부분을 사용자가 직접 프로그래밍 해야한다. 이 프로그램은 아울러, 장애처리를 위한 운영 역할로 전환할 수 있는 기능도 있어야하며, OS 시그널 처리도 있어야 한다.
restore_command 설정값으로 사용될 프로그램의 의사코드는 다음과 같다:
triggered = false;
while (!NextWALFileReady() && !triggered)
{
sleep(100000L); /* wait for ~0.1 sec */
if (CheckForExternalTrigger())
triggered = true;
}
if (!triggered)
CopyWALFileForRecovery();
이런 방식으로 구현된 실재 프로그램을 pg_standby 모듈에서 제공한다. 이 모듈은 위에서 설명한 구현 요소들을 모두 구현했다. 이 모듈과 함께 사용자 정의 스크립트들을 사용해서 구축할 수도 있을 것이다.
어떻게 대기 서버가 운영 서버로 바뀔 것인가에 대한 설계는 꽤 중요한 부분이다. 이 또한 restore_command 설정값으로 지정하는 명령어에서 담당한다. 단순하게 이 명령어의 리턴값이 0 아닌 값으로 종료되면 된다. 0 아닌 값으로 종료되는 상황은 어떤 특정 파일이 생겼을 때, 또는 더 나아가 운영 서버가 응답이 없을 때, 등등 발생할 수 있는 모든 상황을 꼼꼼히 살펴보고 그것을 구현하면 된다. 문제는 이 명령어 실행은 서버가 각 개별 WAL 파일에 대해서 한 번 처리하고, 종료되고, 다시 실행하는 식으로 작동되기 때문에, 서버 데몬과 달리 시그널 처리를 하기 힘들다. 그렇기 때문에, 어떤 특정 파일을 만들어 장애처리 신호로 사용하겠다면, 그 파일은 다른 프로세스가 만드는 것이 타당하다. 한편, 운영 서버의 archive_timeout 값을 참조해서, 원하는 WAL 파일이 넘어오지 않을 경우 다음 작업을 할 수 있는 시간 제한 기능을 둘 수도 있으나, 이 때 네트워크 상태나, 운영 서버의 부하 상태도 함께 고려해야한다. 그렇지 않으면, 의도 되지 않게 장애처리 기능이 작동해서, 상황을 더 악화시킬 수도 있다.
The short procedure for configuring a standby server using this alternative method is as follows. For full details of each step, refer to previous sections as noted.
Set up primary and standby systems as nearly identical as possible, including two identical copies of PostgreSQL at the same release level.
Set up continuous archiving from the primary to a WAL archive directory on the standby server. Ensure that archive_mode, archive_command and archive_timeout are set appropriately on the primary (see 24.3.1절).
Make a base backup of the primary server (see 24.3.2절), and load this data onto the standby.
Begin recovery on the standby server from the local WAL archive, using a recovery.conf that specifies a restore_command that waits as described previously (see 24.3.4절).
Recovery treats the WAL archive as read-only, so once a WAL file has been copied to the standby system it can be copied to tape at the same time as it is being read by the standby database server. Thus, running a standby server for high availability can be performed at the same time as files are stored for longer term disaster recovery purposes.
For testing purposes, it is possible to run both primary and standby servers on the same system. This does not provide any worthwhile improvement in server robustness, nor would it be described as HA.
It is also possible to implement record-based log shipping using this alternative method, though this requires custom development, and changes will still only become visible to hot standby queries after a full WAL file has been shipped.
An external program can call the pg_xlogfile_name_offset()
function (see 9.26절)
to find out the file name and the exact byte offset within it of
the current end of WAL. It can then access the WAL file directly
and copy the data from the last known end of WAL through the current end
over to the standby servers. With this approach, the window for data
loss is the polling cycle time of the copying program, which can be very
small, and there is no wasted bandwidth from forcing partially-used
segment files to be archived. Note that the standby servers'
restore_command scripts can only deal with whole WAL files,
so the incrementally copied data is not ordinarily made available to
the standby servers. It is of use only when the primary dies —
then the last partial WAL file is fed to the standby before allowing
it to come up. The correct implementation of this process requires
cooperation of the restore_command script with the data
copying program.
Starting with PostgreSQL version 9.0, you can use streaming replication (see 25.2.5절) to achieve the same benefits with less effort.