If the primary server fails then the standby server should begin failover procedures. プライマリサーバに障害が起こると、スタンバイサーバはフェイルオーバー処理を始めなければなりません。

If the standby server fails then no failover need take place. If the standby server can be restarted, even some time later, then the recovery process can also be restarted immediately, taking advantage of restartable recovery. If the standby server cannot be restarted, then a full new standby server instance should be created. スタンバイサーバが故障した場合、フェイルオーバーは不要です。 多少の時間の後に、スタンバイサーバを再起動できれば、再起動可能なリカバリのため、リカバリ処理も即座に再起動することができます。 スタンバイサーバを再起動できなければ、新しい完全なスタンバイサーバのインスタンスを作成しなければなりません。

If the primary server fails and the standby server becomes the new primary, and then the old primary restarts, you must have a mechanism for informing the old primary that it is no longer the primary. This is sometimes known as <acronym>STONITH</acronym> (Shoot The Other Node In The Head), which is necessary to avoid situations where both systems think they are the primary, which will lead to confusion and ultimately data loss. プライマリサーバに障害が起こりスタンバイサーバが新しいプライマリとなり、その後古いプライマリが再起動した場合、もはやプライマリサーバでなくなっていることを古いプライマリに知らせる機構が必要です。 これはSTONITH (Shoot the Other Node In The Head)と一部ではいわれています。 これは、混乱と最悪はデータ損失をもたらしかねない、両方のシステムが自身をプライマリとして認識してしまう状況を防ぐために必要です。

Many failover systems use just two systems, the primary and the standby, connected by some kind of heartbeat mechanism to continually verify the connectivity between the two and the viability of the primary. It is also possible to use a third system (called a witness server) to prevent some cases of inappropriate failover, but the additional complexity might not be worthwhile unless it is set up with sufficient care and rigorous testing. 多くのフェイルオーバーシステムではプライマリとスタンバイといった２つのシステムを使用します。 なんらかのハートビート機構でプライマリとスタンバイを接続し、両者の接続性とプライマリの実行能力を継続的に確認します。 また、第３のシステム（witnessサーバと呼ばれます）を使用して、不適切なフェイルオーバーなどの状況を防ぐこともできます。 しかし、さらに複雑になりますので、十分な注意と厳密な検証の元に設定を行わない限り行う意味がありません。

<productname>PostgreSQL</productname> does not provide the system software required to identify a failure on the primary and notify the standby database server. Many such tools exist and are well integrated with the operating system facilities required for successful failover, such as IP address migration. PostgreSQLは、プライマリサーバの障害を識別し、スタンバイデータベースサーバに通知するために必要なシステムソフトウェアを提供しません。 こうしたツールは多く存在し、IPアドレスの移行といったフェイルオーバーを成功させるために必要な機能をオペレーティングシステムにうまく統合させています。

Once failover to the standby occurs, there is only a single server in operation. This is known as a degenerate state. The former standby is now the primary, but the former primary is down and might stay down. To return to normal operation, a standby server must be recreated, either on the former primary system when it comes up, or on a third, possibly new, system. The <xref linkend="app-pgrewind"/> utility can be used to speed up this process on large clusters. Once complete, the primary and standby can be considered to have switched roles. Some people choose to use a third server to provide backup for the new primary until the new standby server is recreated, though clearly this complicates the system configuration and operational processes. スタンバイサーバへのフェイルオーバーが起きた後、運用可能なサーバは1つしかありません。 これは縮退状態と呼ばれます。 以前のスタンバイサーバはプライマリサーバになり、以前のプライマリは停止し、その後も停止し続けるかもしれません。 通常の運用に戻すには、スタンバイサーバを再作成しなければなりません。 以前のプライマリサーバが起動できれば、これを使用しても構いませんし、第三のおそらく新規のシステムを使用しても構いません。 pg_rewindを使って、大きなクラスタにおける処理を早めることもできます。 完了すれば、プライマリとスタンバイの役割が切り替わったとみなすことができます。 新しいスタンバイサーバを再作成するまでに第三のサーバを使用して新しいプライマリのバックアップを提供することを選択する人もいますが、これがシステム構成と運用手順を複雑にすることは明らかです。

So, switching from primary to standby server can be fast but requires some time to re-prepare the failover cluster. Regular switching from primary to standby is useful, since it allows regular downtime on each system for maintenance. This also serves as a test of the failover mechanism to ensure that it will really work when you need it. Written administration procedures are advised. プライマリサーバからスタンバイサーバへの切り替えは高速ですが、フェイルオーバークラスタを再度準備するのに多少時間が必要です。 それぞれのシステムを保守のために定期的に停止することができるので、プライマリからスタンバイへの定期的切り替えは有益です。 これは同時に、必要になった時、フェイルオーバー機構が実際に機能するかどうかを確認する試験としても役立ちます。 管理手順の文書化を勧めます。

If you have opted for logical replication slot synchronization (see <xref linkend="logicaldecoding-replication-slots-synchronization"/>), then before switching to the standby server, it is recommended to check if the logical slots synchronized on the standby server are ready for failover. This can be done by following the steps described in <xref linkend="logical-replication-failover"/>. 《機械翻訳》ロジカルレプリケーションスロットの同期化（47.2.3を参照）を選択した後、前をスタンバイサーバに切り替えた場合、スタンバイサーバで同期化されたロジカルスロットがチェックの準備ができていれば、フェイルオーバーに切り替えることをお勧めします。 これは、29.3で説明されている手順に従って行うことができます。

To trigger failover of a log-shipping standby server, run <command>pg_ctl promote</command> or call <function>pg_promote()</function>. If you're setting up reporting servers that are only used to offload read-only queries from the primary, not for high availability purposes, you don't need to promote. ログシッピングスタンバイサーバのフェイルオーバーを開始するには、pg_ctl promoteを実行するか、pg_promote()を呼び出します。 高可用性目的ではなく、 読み取り専用の問い合わせをプライマリからオフロードするためだけに使用するレポートサーバを設定する場合は、昇格する必要はありません。