25.4. 로그 전달을 위한 대체 범퍼카 토토

이전 섹션에서 설명한 내장 대기 모드의 대안은 다음을 사용하는 것입니다.restore_command보관 위치를 폴링합니다. 이는 버전 8.4 이하에서 사용할 수 있는 유일한 옵션이었습니다. 이 설정에서는 다음을 설정합니다.대기_모드off, 대기 작업에 필요한 폴링을 직접 구현하고 있기 때문입니다. 참조postgresql이것의 참조 구현을 위한 모듈입니다.

이 모드에서는 서버가 한 번에 하나의 파일씩 WAL을 적용하므로 쿼리를 위해 대기 서버를 사용하는 경우(핫 대기 참조) 마스터의 작업과 작업이 대기에서 표시될 때 WAL 파일을 채우는 데 걸리는 시간에 따라 지연이 있습니다.archive_timeout지연 시간을 단축하는 데 사용할 수 있습니다. 또한 스트리밍 복제를 이 범퍼카 토토과 결합할 수 없습니다.

기본 및 대기 서버 모두에서 발생하는 작업은 일반적인 연속 보관 및 복구 작업입니다. 두 데이터베이스 서버 사이의 유일한 접촉 지점은 둘 다 공유하는 WAL 파일의 아카이브입니다. 즉, 아카이브에 대한 기본 쓰기와 아카이브에서 대기 읽기를 공유합니다. 별도의 기본 서버에 있는 WAL 아카이브가 서로 섞이거나 혼동되지 않도록 주의해야 합니다. 대기 작업에만 필요한 경우 아카이브가 클 필요는 없습니다.

느슨하게 연결된 두 서버를 함께 작동하게 만드는 마법은 간단합니다.restore_command다음 WAL 파일을 요청할 때 기본에서 사용할 수 있을 때까지 기다리는 대기에서 사용됩니다.restore_command다음에 지정됨recovery.conf파일을 대기 서버에 저장하세요. 일반적인 복구 처리에서는 WAL 아카이브의 파일을 요청하고 파일을 사용할 수 없는 경우 실패를 보고합니다. 대기 처리의 경우 다음 WAL 파일을 사용할 수 없는 것은 정상이므로 대기는 해당 파일이 나타날 때까지 기다려야 합니다. 다음으로 끝나는 파일의 경우:.역사기다릴 필요가 없으며 0이 아닌 반환 코드가 반환되어야 합니다. 대기restore_command다음 WAL 파일의 존재 여부를 폴링한 후 반복하는 사용자 정의 스크립트로 작성할 수 있습니다. 장애 조치를 트리거하는 방법도 있어야 하며, 이로 인해restore_command, 루프를 중단하고 파일을 찾을 수 없다는 오류를 대기 서버에 반환합니다. 이렇게 하면 복구가 종료되고 대기 서버가 일반 서버로 나타납니다.

적합한 의사 코드restore_command다음과 같습니다:

트리거됨 = false;
while (!NextWALFileReady() && !트리거됨)

    수면(100000L);         /* ~0.1초 동안 기다림 */
    if(CheckForExternalTrigger())
        트리거 = 사실;

기다림의 실제 사례restore_command다음에서 제공됩니다.postgresql모듈. 위에서 설명한 논리를 올바르게 구현하는 방법에 대한 참조로 사용해야 합니다. 특정 구성 및 환경을 지원하기 위해 필요에 따라 확장할 수도 있습니다.

장애 조치를 실행하는 방법은 계획 및 설계에서 중요한 부분입니다. 한 가지 잠재적인 옵션은 다음과 같습니다.restore_command명령. 이는 각 WAL 파일에 대해 한 번씩 실행되지만, 다음을 실행하는 프로세스는restore_command파일마다 생성되고 죽기 때문에 데몬이나 서버 프로세스가 없고 시그널이나 시그널 핸들러를 사용할 수 없습니다. 그러므로,restore_command장애 조치를 실행하는 데 적합하지 않습니다. 특히 알려진 것과 함께 사용되는 경우 간단한 시간 초과 기능을 사용할 수 있습니다.archive_timeout기본 설정. 그러나 네트워크 문제나 사용량이 많은 기본 서버만으로도 장애 조치를 시작할 수 있으므로 이는 다소 오류가 발생하기 쉽습니다. 트리거 파일을 명시적으로 생성하는 등의 알림 메커니즘이 이상적이라면 가능합니다.