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

대기 서버가 실패하면 장애 조치가 필요하지 않습니다. 대기 서버를 다시 시작할 수 있으면 일정 시간이 지난 후에도 다시 시작 가능한 복구를 활용하여 복구 프로세스를 즉시 다시 시작할 수도 있습니다. 대기 서버를 다시 시작할 수 없는 경우 완전히 새로운 대기 서버 인스턴스를 생성해야 합니다.

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

많은 장애 조치 시스템은 일종의 하트비트 메커니즘으로 연결된 기본 및 대기 시스템 두 개만 사용하여 두 시스템 간의 연결과 기본 시스템의 실행 가능성을 지속적으로 확인합니다. 일부 부적절한 장애 조치를 방지하기 위해 세 번째 시스템(감시 서버라고 함)을 사용하는 것도 가능하지만 충분한 주의와 엄격한 테스트를 통해 설정하지 않으면 추가 복잡성을 감당할 가치가 없을 수도 있습니다.

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

대기 서버로 장애 조치가 발생하면 단일 서버만 작동됩니다. 이는 퇴화된 상태로 알려져 있습니다. 이전 대기는 이제 기본이지만 이전 기본은 작동 중지되었으며 계속 작동 중지 상태일 수 있습니다. 정상 작동으로 돌아가려면 이전 기본 시스템이 나타날 때나 세 번째(가능한 경우 새로운) 시스템에서 대기 서버를 다시 생성해야 합니다. 그만큼pg_rewind유틸리티를 사용하면 대규모 클러스터에서 이 프로세스의 속도를 높일 수 있습니다. 완료되면 기본 및 대기의 역할이 전환된 것으로 간주될 수 있습니다. 일부 사람들은 새 대기 서버가 다시 생성될 때까지 새 기본 서버에 대한 백업을 제공하기 위해 세 번째 서버를 사용하기로 선택합니다. 하지만 이는 분명히 시스템 구성 및 운영 프로세스를 복잡하게 만듭니다.

따라서 기본 서버에서 대기 서버로 전환하는 것은 빠르지만 장애 조치 클러스터를 다시 준비하는 데 시간이 좀 걸립니다. 기본에서 대기로 정기적으로 전환하면 유지 관리를 위해 각 시스템에 정기적인 가동 중지 시간이 허용되므로 유용합니다. 이는 또한 필요할 때 실제로 작동하는지 확인하기 위한 장애 조치 메커니즘 테스트 역할도 합니다. 서면 관리 절차를 따르는 것이 좋습니다.

논리적 복제 슬롯 동기화를 선택한 경우(참조섹션 47.2.3), 그런 다음 대기 서버로 전환하기 전에 대기 서버에 동기화된 논리 슬롯이 장애 조치 준비가 되었는지 확인하는 것이 좋습니다. 이 작업은 다음에 설명된 단계에 따라 수행할 수 있습니다.PostgreSQL : 문서 : 17 : 29.3. 논리적 롤 토토 장애 조치.

로그 전달 대기 서버의 장애 조치를 실행하려면 다음을 실행하십시오.pg_ctl 승격또는 전화pg_promote(). 고가용성 목적이 아닌 기본 쿼리에서 읽기 전용 쿼리를 오프로드하는 데만 사용되는 보고 서버를 설정하는 경우 승격할 필요가 없습니다.