| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 23. 백업과 복원 | Fast Forward | Next |
계속적 어카이브를 사용해, 주 서버가 정지했을 때 연산을 이어 받을 준비가 된 1개 이상의스탠바이 서버로고가용성 (HA) 클러스터 설정을 사용할 수 있습니다. 이 기능은 빈번히 warm standby나 로그 shipping으로 언급됩니다.
이 기능을 위해서 주 서버와 스탠바이 서버는 함께 동작하지만, 서버 간의 관계는 밀접하지 않습니다. 주 서버는 계속적 어카이브 모드로 동작하고, 각 스탠바이 서버는 계속적 복구 모드로 동작해, 프라이머리로부터의 WAL 파일을 읽어냅니다. 이 기능을 유효하게 하기 위해서, 데이터베이스 테이블을 변경할 필요는 없습니다. 그러므로, 다른 복제(replication) 수법과 비교해, 관리와 관련되는 오버헤드가 낮아집니다. 또한, 이 설정이 주 서버에게 주는 성능 영향도 상대적으로 낮습니다.
하나의 데이터베이스 서버에서 다른 곳으로 WAL 이 이동하는 것은 보통, log shipping이라고 표현됩니다. PostgreSQL는 파일 베이스 log shipping을 실행합니다. 이는 WAL 기록이 바로 하나의 파일(WAL 세그먼트)로 전송되는 것을 의미합니다. WAL파일은 간편하고 저렴한 방법으로 근접한 시스템이나 다른 시스템의 같은 사이트, 지구 반대편의 다른 시스템든지 상관하지 않고, 어느 곳으로도 전송될 수 있습니다. 이 기술을 위해서 필요한 대역은 주 서버의 트랜잭션 비율에 따라 바뀝니다. 또한, 기록 베이스의 log shipping도 절차를 독자적으로 개발할 수 있습니다. Section 23.4.4에서 설명하고 있습니다.
log shipping이 비동기라는 것을 주의해야 합니다. 즉, 트랜잭션이 처리된 후에 WAL 기록이 전송 됩니다. 이 결과, 주 서버에 파멸적인 실패가 일어나, 전송 전의 트랜잭션이 없어졌을 경우, 데이터 손실 기간이 존재하게 됩니다. archive_timeout파라미터를 사용하는 것으로, 데이터 손실 기간을 제한할 수 있습니다. 이 파라미터는 필요하면 몇 초 정도까지 설정할 수 있습니다. 그러나 이러한 작은 값은 파일 전송에 필요한 대역을 크게 증대시킵니다. 1분 미만 정도의 데이터 손실 기간이 필요하면, 기록 베이스의 log shipping을 검토하는 편이 좋을 것입니다.
스탠바이 서버는 계속적으로 복구 처리를 실시하고 있기 때문에, 액세스에는 이용할 수 없습니다. 복구 작업효율은 스탠바이 서버가 완전히 이용되는 것으로부터 멀어지는 것은 일시적이기 때문에 충분히 좋습니다. 결과적으로 이 능력을, 고가용성을 제공하기 위한 warm standby 설정으로서 참조합니다. 보관된 기본 백업으로부터 서버의 복구와 롤 포워드는 오랜 시간이 걸릴 것입니다. 이 때문에, 이 기법은 고가용성이 아닌 재해 복구시 대책을 제공할 뿐입니다.
적어도 데이터베이스 서버의 견지로부터, 할 수 있는 한 모조 형태로 주 서버와 스탠바이 서버를 작성하는 것이 일반적인 추천입니다. 구체적으로 테이블 공간에 관련한 경로명은 그대로 건네받기 때문에, 테이블 공간 기능을 사용하는 경우는 주 서버와 스탠바이 서버의 테이블 공간용의 마운트 포인트를 동일하게 할 필요가 있습니다. 주 서버로 CREATE TABLESPACE 를 실행하는 경우, 커맨드를 실행하기 전에, 필요한 새로운 마운트 포인트를 주 서버, 스탠바이 서버의 양쪽 모두로 작성해야 하는 것은 기억해 주십시요. 하드웨어는 정확하게 같은 필요는 없습니다. 그러나 경험상, 어플리케이션과 시스템의 유효기간을 통해, 2개이 다른 시스템을 관리하는 것보다 2개의 동일한 시스템을 관리하는 편이 간단합니다. 어쨌든 하드웨어 아키텍처는 같지 않으면 안됩니다. 예를 들어, 32 비트 시스템으로부터 64 비트 시스템에의 선박은 잘 동작하지 않습니다.
보통, 다른 메이저 릴리스 단계의 서버 사이에서는 log shipping이 불가능합니다. 메이저 릴리스의 업데이트 기간은 디스크 서식을 변경하지 않는다는 것이 PostgreSQL 글로벌 개발 그룹의 방침이므로, 주 서버와 스탠바이 서버와의 사이에 메이저 릴리스 단계에 차이가 있어도 잘 동작할 것입니다. 그러나 이 경우, 공식적인 지원은 제공되지 않습니다. 할 수 있는 한 주 서버와 스탠바이 서버로 같은 릴리스 레벨을 사용하십시요. 새로운 메이저 릴리스에 업데이트하는 경우, 가장 안전한 방침은 스탠바이 서버를 먼저 업데이트하는 것입니다. 새로운 메이저 릴리스는 이전의 메이저 릴리스의 WAL 파일을 읽어들일 수 있지만, 반대는 할 수 없을지도 모릅니다.
스탠바이 서버를 사용하기 위해 필요한 특수한 모드는 존재하지 않습니다. 주 서버와 스탠바이 서버에서 발생하는 연산은 전체적으로 일반적인 계속적 어카이브와 복구 작업입니다. 2개의 데이터베이스 서버가 관계하는 유일한 지점은 공유되는 WAL 파일의 어카이브입니다. 주 서버는 이 어카이브를 입력하고, 스탠바이 서버는 이것을 읽어들입니다. 그렇지 않으면 혼란스러워집니다. 분리된 주 서버의 WAL 어카이브가 섞이지 않도록 주의해야 합니다.
밀접하지 않은 두 서버를 함께 작동시키기 위해서는 간단히 스탠바이 서버에서 사용하는 restore_command를 이용하면 됩니다. 이것은 주 서버로부터 사용가능한 다음 WAL 파일을 스탠바이 서버가 기다리도록 합니다. 이restore_command는 스탠바이 서버의recovery.conf파일로 지정됩니다. 보통의 복구 처리는 WAL로부터 파일을 요구해, 파일을 이용할 수 없으면 실패합니다. 스탠바이 처리에서는 일반적으로 다음 파일을 이용할 수 없기 때문에, 이용 가능하게 될 때까지 대기해야 합니다. restore_command를 대기시키려면, 다음 WAL 파일의 존재를 확인한 후, 루프하는 커스텀 스크립트를 작성하여 실현될 수 있습니다. 또한 트리거가 실패하는 몇 가지 방법이 있어야 합니다. 이는 restore_command를 방해해, 루프를 종료시키고, 파일이 존재하지 않는다는 에러를 스탠바이 서버에 돌려주는 것입니다. 이것은 복구 처리를 정지시키기 때문에, 스탠바이 서버는 보통의 서버가 됩니다.
restore_command에 적절한 의사 코드를 이하에 나타냅니다.
triggered = false;
while (!NextWALFileReady() && !triggered)
{
sleep(100000L); /* wait for ~0.1 sec */
if (CheckForExternalTrigger())
triggered = true;
}
if (!triggered)
CopyWALFileForRecovery();
PostgreSQL는 주 서버의 실패를 식별해, 스탠바이 시스템, 스탠바이 데이터베이스 서버에 통지하는데 필요한 시스템 소프트웨어를 제공하지 않습니다. 이러한 툴은 많이 존재하고 있으며, 이것들에는 IP주소를 이동시키는 것과 같은, 다른 failover를 성공시키기 위한 기능을 가지고 있습니다.
failover 트리거를 위한 방법은 계획하고 설계하는 데 중요한 부분입니다. restore_command는 각 WAL 파일에서 한 번 밖에 실행되지 않습니다. restore_command를 실행하는 프로세스는 각 파일을 생성하거나 삭제합니다. 또한, demon나 서버 프로세스가 없기 때문에, 시그널이나 시그널 핸들러를 사용할 수 없습니다. failover의 통지에는 보다 오래 가는 통지 기능이 필요합니다. 순수한 타임 아웃 기능을 사용할 수 있습니다. 주로 주 서버상의 기존의archive_timeout설정과 연계해 사용됩니다. 네트워크 장애나 고부하인 주 서버에 의해 failover가 시작되기 때문에, 에러가 발생하기 쉽습니다. 지정 할 수 있다면, 명시적인 트리거 파일 생성과 같은 통지 매커니즘은 에러가 되기 어렵습니다.
스탠바이 서버를 설정하기 위한 간략한 절차를 이하에 나타냅니다. 각 단계의 상세한 점은 이전 절을 참조해 주십시요.
할 수 있는 한 똑같이 주 시스템과 스탠바이 시스템을 설정해 주십시요. 같은 릴리스 레벨의PostgreSQL의 복제도 포함합니다.
계속적 아케이브를 주 서버에서 스탠바이 서버의 디렉토리상에 WAL를 보관하도록 설정해 주십시요. 주 서버로 archive_command 및 archive_timeout이 적절히 설정되어있는지 확인해 주십시요(Section 23.3.1를 참조해 주십시요).
주 서버로 기본 백업을 작성(Section 23.3.2를 참조해 주십시요)하고, 스탠바이 서버로 이 데이터를 로드해 주십시요.
로컬 WAL 어카이브로부터 스텐바이 서버의 복구를 시작하고, 사전에 설명한 대기를 실행하는 restore_command를 지정한recovery.conf를 사용하십시요. (Section 23.3.3를 참조해 주십시요. )
복구는 WAL 어카이브를 read만을 다룹니다. 이 때문에, WAL 파일이 스탠바이 시스템에 카피된 후, 스탠바이 데이터베이스 서버에 의한 read와 동시에 WAL 파일을 테이프에 복제할 수 있습니다. 이와 같이, 고가용성 스탠바이 서버의 실행은 장기 재해 복구 목적을 위해서 보관과 동시에 실행될 수 있습니다.
테스트를 위해, 주 서버와 스탠바이 서버를 같은 시스템으로 가동시킬 수 있습니다. 이것에 의해 서버 건전성이 향상하거나, 설명한 HA로 작동하지도 않습니다.
주 서버에 장애가 일어나면, 스탠바이 서버는 failover 처리를 시작해야 합니다.
스탠바이 서버에 장애가 일어나면, failover는 실행되지 않습니다. 약간의 시간이 흐르고, 스탠바이 서버를 재시작할 수 있으면, 재시작 가능한 복구를 위해, 복구 프로세스도 즉석에서 재시작합니다. 스탠바이 서버를 재시작할 수 없으면, 완전히 새로운 스탠바이 서버 인스턴스가 작성되어야만 합니다.
주 서버에 장애가 일어나고, 그 후 곧바로 재시작했을 경우, 더이상 주 서버가 아님을 알리는 매커니즘이 필요합니다. 이것은 STONITH (Shoot the Other Node In The Head)로 알려져 있습니다. 이는 혼란과 최악의 경우 데이터 손실을 가져오는, 두 시스템이 자신을 주 서버로 인식하는 상황을 막기 위해서 필요합니다.
많은 failover시스템에서는 2개의 시스템을 사용합니다. heartbeat 매커니즘와 같은 방법으로 주 서버와 스탠바이 서버를 접속해, 양자의 접속성과 프라이머리의 실행 능력을 계속적으로 확인합니다. 또한, 제3의 시스템(증언 서버로 불립니다)을 사용해, 부적절한 failover등의 상황을 막을 수도 있습니다. 그러나 한층 더 복잡해 지기 때문에, 충분한 주의와 엄밀한 검증을 하지 않는 한 실시하는 의미가 없습니다.
스탠바이 서버에서 failover가 발생한 경우, 운용 가능한 서버는 1개 밖에 없습니다. 이것은 퇴화 상태로서 알려집니다. 이전의 스탠바이 서버는 주 서버가 되고, 이전의 주 서버는 정지되었고, 정지 상태로 머물 것입니다. 일반적인 운용상태로 되돌리려면, 스탠바이 서버를 재작성해야 합니다. 작동 가능한 이전의 주 서버나 제３, 또는 신규 시스템을 사용해도 상관없습니다. 완료되면, 주 서버와 스탠바이 서버의 역할이 바뀌었다고 간주할 수 있습니다. 새로운 스탠바이 서버를 재작성할 때까지 제3의 서버를 사용해 새로운 주 서버의 백업을 제공하는 것을 선택하는 사람도 있지만, 이것이 시스템 설정과 운용 순서를 복잡하게 만듭니다.
주 서버에서 스탠바이 서버로의 변환은 빠를 수 있어, failover 클러스터를 재준비하는데 다소 시간이 걸립니다. 각각의 시스템은 보수를 위해서 정기적으로 정지할 수 있으므로, 주 서버에서 스탠바이 서버로의 정기적 변환은 유용합니다. 이것은 동시에 필요할 때, failover 매커니즘이 실제로 가능한 지를 확인하는 시험이라고 해도 도움이 됩니다. 관리 순서의 문서화를 권합니다.
지금까지 설명한 것처럼PostgreSQL는 파일 베이스의 log shipping을 직접 지원합니다. 기록 베이스의 log shipping을 실행하는 일도 가능하지만, 이것은 독자적인 개발이 필요합니다.
외부 프로그램으로부터, WAL의 현재의 종료점의 파일명과 정확한 바이트 오프셋(offset)를 찾아내는 pg_xlogfile_name_offset()함수(Section 9.20를 참조)를 호출할 수 있습니다.
그리고 WAL 파일에 직접 액세스 해, 직전의 WAL 종료점으로부터 현재의 종료점까지의 데이터를 스탠바이 서버에 카피할 수 있습니다.
이 방법에서 데이터 손실 기간은 카피 처리 프로그램의 실행 주기가 됩니다.
아주 작지만, 강제적으로 부분 사용된 세그먼트 파일을 보관하기 위한 쓸데없는 대역폭은 없습니다.
스탠바이 서버의restore_command스크립트가 WAL 파일 전체를 계속 다룬 다는 것을 주의해 주십시요.
이 때문에, 순서대로 카피한 데이터는 보통은 스탠바이 서버로 이용할 수 없습니다.
주 서버가 정지해 재시작하기 전까지 마지막 부분적인 WAL 파일이 스탠바이 서버에게 건네질 경우만 사용할 수 있습니다.
이 때문에, 이 처리를 제대로 실행하기 위해서는 데이터 카피 프로그램과 restore_command스크립트와의 연계가 필요합니다.
warm standby 구성에서 주 서버로부터 정기적인 기본 백업을 실시하는 수고를 생략할 수 있습니다. 대신에, 스탠바이 서버의 파일을 백업 하는 것으로 기본 백업을 작성할 수 있습니다. 이 개념은 증가되는 업데이트된 백업, 로그 변경 누적, 또는 간단히 변경의 누적이라고 말해집니다.
주 서버로부터의 log shipping을 처리하고 있는 동안에, 스탠바이 서버의 데이터 디렉토리를 백업 했을 경우, 그 데이터를 리로드 해, 스탠바이 서버의 복구 처리를 직전의 재시작점으로부터 시작 할 수 있습니다. 재시작점 이전의 WAL 파일을 보관 유지할 필요는 없어집니다. 복구가 필요하게 되면, 원래 기본 백업으로부터의 복구보다 점차 증가된 업데이트된 백업으로부터의 복구가 빠르게 이루어 질 것입니다.
스탠바이 서버는 "활동 상태"가 아니기 때문에, 백업 처리를 관리하기 위해pg_start_backup()와 pg_stop_backup()를 사용할 수 없습니다.
어떻게 WAL 세그먼트 파일을 보관해 복구 가능한 백업을 가지는 가는 관리자에게 달려있습니다.
스탠바이 서버로pg_controldata를 실행해, 제어 파일을 검사하고,
현재의 체크 포인트 WAL 위치를 결정할 수 있습니다.