25.3. 장애 조치

주 서버가 실패하면 대기 서버는 다음을 수행해야 합니다. 장애 조치 절차를 시작합니다.

대기 서버가 실패하면 장애 조치가 발생하지 않습니다. 시간이 좀 지나더라도 대기 서버를 다시 시작할 수 있게 된다면, 그런 다음 복구 프로세스를 즉시 다시 시작할 수도 있습니다. 재시작 가능한 복구를 활용합니다. 대기 서버인 경우 다시 시작할 수 없는 경우 완전히 새로운 대기 서버 인스턴스 생성되어야 합니다.

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

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

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

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

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

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