25.3. 장애 조치

기본 서버가 실패하면 대기 서버가 시작되어야 합니다 장애 조치 절차.

대기 서버가 실패하면 장애 조치가 발생하지 않습니다. 만약에 대기 서버는 일정 시간이 지난 뒤에도 다시 시작할 수 있습니다. 복구 프로세스를 즉시 다시 시작할 수도 있습니다. 재시작 가능한 복구의 이점. 대기 서버가 연결되지 않는 경우 다시 시작하면 완전히 새로운 대기 서버 인스턴스가 있어야 합니다. 생성되었습니다.

주 서버가 실패하고 대기 서버가 새 기본이 있고 이전 기본이 다시 시작되면 이전 기본 노드에 더 이상 기본 노드가 아님을 알리는 메커니즘 기본. 이것은 때때로 다음과 같이 알려져 있습니다.스토니스(머리에 있는 다른 노드를 쏴라), 이는 두 시스템이 모두 생각하는 상황을 피하기 위해 필요합니다. 이는 혼란을 야기하고 궁극적으로 데이터 손실.

많은 장애 조치 시스템은 기본 시스템과 기본 시스템, 두 개의 시스템만 사용합니다. 일종의 하트비트 메커니즘으로 연결된 대기 지속적으로 둘 사이의 연결을 확인합니다. 기본의 생존 가능성. 세 번째 시스템을 사용하는 것도 가능합니다 (증인 서버라고 함) 일부 부적절한 경우를 방지하기 위해 장애 조치가 가능하지만 복잡성이 추가되는 것은 가치가 없을 수 있습니다. 충분한 주의와 엄격한 테스트를 거쳐 설정되지 않은 경우.

포스트그레SQL제공하지 않습니다. 기본 및 대기 데이터베이스 서버에 알립니다. 그러한 도구가 많이 존재하며 필요한 운영 체제 기능과 잘 통합되어 있습니다. IP 주소 마이그레이션과 같은 성공적인 장애 조치.

대기 모드로의 장애 조치가 발생하면 단일 서버 운영중입니다. 이는 퇴화된 상태로 알려져 있습니다. 는 이전 대기가 이제 기본이 되었지만 이전 기본이 다운되었습니다. 그리고 가만히 있을 수도 있어요. 정상 작동으로 돌아가려면 대기 다음 경우 이전 기본 시스템에서 서버를 다시 생성해야 합니다. 또는 세 번째, 아마도 새로운 시스템이 나타납니다. 완료되면, 기본 및 대기는 역할이 전환된 것으로 간주될 수 있습니다. 어떤 사람들은 백업을 제공하기 위해 세 번째 서버를 사용하기로 선택합니다. 하지만 새 대기 서버가 다시 생성될 때까지 새 기본 서버는 분명히 이는 시스템 구성과 운영을 복잡하게 만듭니다. 프로세스.

따라서 기본 서버에서 대기 서버로 전환하는 것은 빠를 수 있지만 장애 조치 클러스터를 다시 준비하는 데 약간의 시간이 필요합니다. 레귤러 기본에서 대기로 전환하는 것은 유용합니다. 유지 관리를 위해 각 시스템을 정기적으로 가동 중지합니다. 이것은 또한 봉사한다 장애 조치 메커니즘을 테스트하여 실제로 작동하는지 확인합니다. 필요할 때 일하세요. 서면 관리 절차는 다음과 같습니다. 조언했습니다.

로그 전달 대기 서버의 장애 조치를 실행하려면 다음을 실행하십시오.pg_ctl 승격또는 트리거 파일 생성 에서 지정한 파일 이름과 경로를 사용합니다.trigger_file설정recovery.conf. 사용할 계획이라면pg_ctl 승격장애 조치를 위해,trigger_file필요하지 않습니다. 설정하는 경우 읽기 전용을 오프로드하는 데만 사용되는 보고 서버 고가용성 목적이 아닌 기본 데이터베이스의 쿼리 홍보할 필요는 없습니다.