-->
<title>フェイルオーバとフェイルバック</title>
- <sect2 id="runtime-config-failover-settings">
+ <para>
+ フェイルオーバは、<productname>Pgpool-II</productname>から見て使用できなくなった<productname>PostgreSQL</productname>バックエンドノードを<productname>Pgpool-II</productname>が自動的に切り離す処理を指します。
+ これは<productname>Pgpool-II</productname>の設定に関わらず、自動的に行われるいわゆる<emphasis>自動フェイルオーバ</emphasis>処理です。
+ <productname>Pgpool-II</productname>は<productname>PostgreSQL</productname>バックエンドノードが使用できなくなったことを、以下の方法で確認します。
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ 定期的に実行されるヘルスチェック処理で確認する(詳細は<xref linkend="runtime-config-health-check">を参照)。
+ ヘルスチェックは、<productname>Pgpool-II</productname>から<productname>PostgreSQL</productname>バックエンドノードへ接続を試行することによって<productname>PostgreSQL</productname>バックエンドノードが正常に動いていることを確認します。
+ 正常に接続できない場合、<productname>Pgpool-II</productname>から<productname>PostgreSQL</productname>へのネットワーク接続のどこかがおかしいか、<productname>PostgreSQL</productname>自体が正常に動作していないか、あるいはその両方である可能性がありますが、<productname>Pgpool-II</productname>はそれを特に区別せず、単にヘルスチェックが失敗したら、該当<productname>PostgreSQL</productname>ノードが使用できないと判断します。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <productname>PostgreSQL</productname>ノードへの接続の際、あるいは接続中にネットワークレベルのエラーが発生した場合。
+ ただし、<xref linkend="guc-failover-on-backend-error">がオフの場合はそのようなエラーの場合でも<productname>Pgpool-II</productname>は単にエラーをレポートしセッションが切断するのみです。
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ クライアントが<productname>Pgpool-II</productname>に接続済みであり、<productname>PostgreSQL</productname>においてシャットダウン処理が実施された場合（クライアントがまったく<productname>Pgpool-II</productname>に接続していない場合は、<productname>PostgreSQL</productname>がシャットダウンされてもフェイルオーバしないことに注意してください）。
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ </para>
+
+ <para>
+ <xref linkend="guc-failover-command">が設定済みでフェイルオーバが行われると、<xref linkend="guc-failover-command">が起動されます。
+ <xref linkend="guc-failover-command">はユーザが記述すべきもので、主な役割としては、たとえばストリーミングレプリケーションのプライマリサーバがダウンした時に、新しいプライマリサーバをスタンバイサーバの中から選択して昇格させることなどが上げられます。
+ そのほか、ファイルオーバが発生したことを管理者にメールで通知することなども考えられます。
+ </para>
+
+ <para>
+ フェイルオーバはこのように障害時に発生しますが、手動で意図的にフェイルオーバさせることもできます。
+ これを<emphasis>スイッチオーバ</emphasis>と呼びます。
+ たとえば、スィッチオーバで<productname>PostgreSQL</productname>を意図的に切り離して、その間にバックアップを取得するなどの運用が考えられます。
+ スィッチオーバでは、単に<productname>Pgpool-II</productname>内の状態情報をダウン状態にするだけ（ただし、<xref linkend="guc-failover-command">は起動される）で、<productname>PostgreSQL</productname>をダウンさせるわけではないことに注意してください。
+ スィッチオーバは<xref linkend="PCP-DETACH-NODE">コマンドで実行できます。
+ </para>
+
+ <para>
+ フェイルオーバないしスィッチオーバで切り離された<productname>PostgreSQL</productname>ノードは、自動ではもとの状態（アタッチ状態）には戻りません。
+ -D オプションを指定して<productname>Pgpool-II</productname>を再起動するか、<xref linkend="PCP-ATTACH-NODE">コマンドを使用します。
+ その際、<xref linkend="SQL-SHOW-POOL-NODES">を使って、replication_stateが"streaming"になっていることを確認することをお勧めします。
+ これは、スタンバイサーバがプライマリサーバとストリーミングレプリケーションで正常に接続されており、データベース内容の整合性が取れていることを示します。
+ </para>
+ <sect2 id="runtime-config-failover-settings">
<!--
<title>Failover and Failback Settings</title>
-->
<sect1 id="runtime-config-failover">
<title>Failover and Failback</title>
+ <para>
+ Failover means automatically
+ detaching <productname>PostgreSQL</productname>backend node which
+ is not accessible by <productname>Pgpool-II</productname>. This
+ happens automatically regardless the configuration parameter
+ settings and is so called <emphasis>automatic failover</emphasis>
+ process. <productname>Pgpool-II</productname> confirms the
+ inacceibility of <productname>PostgreSQL</productname> backend
+ node by using following methods:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Regular health check process
+ (see <xref linkend="runtime-config-health-check"> for more
+ details). The heath check process tries to connect
+ from <productname>Pgpool-II</productname>
+ to <productname>PostgreSQL</productname> node to confirm
+ its healthiness. If it fails to connect, it is possible
+ that there's something wrong with network connection
+ between <productname>Pgpool-II</productname>
+ and <productname>PostgreSQL</productname>,
+ and/or <productname>PostgreSQL</productname> does not work
+ properly. <productname>Pgpool-II</productname> does not
+ distinguish each case and just decides that the
+ particular <productname>PostgreSQL</productname> node is
+ not available if health check fails.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ An error occurs while connecting
+ to <productname>PostgreSQL</productname>, or network level
+ erros occur while communicating with it.
+ <productname>Pgpool-II</productname> will just disconnect
+ the session to client
+ if <xref linkend="guc-failover-on-backend-error"> is off in
+ that case However.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ In the case When clients already connect
+ to <productname>Pgpool-II</productname>
+ and <productname>PostgreSQL</productname> is shutdown
+ (please note that if no client connects
+ to <productname>Pgpool-II</productname> at all, shutting
+ down of <productname>PostgreSQL</productname> does not
+ trigger a failover).
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ </para>
+
+ <para>
+ If <xref linkend="guc-failover-command"> is configured and a
+ failover happens, <xref linkend="guc-failover-command"> gets
+ executed. <xref linkend="guc-failover-command"> should be
+ provided by user and the major role is choosing new primary
+ server from existing standby servers and promoting it for
+ example. Another example would be let the administrator know that
+ a failover happens by sending a mail.
+ </para>
+
+ <para>
+ While a failover could happen when a failure occurs, it is
+ possible to trigger it by hand. This is called a <emphasis>switch
+ over</emphasis>. For instance, switching over
+ a <productname>PostgreSQL</productname> to take its backup would
+ be possible. Note that switching over just sets the status to
+ down and never bringing <productname>PostgreSQL</productname>
+ down. A switch over can be triggered by
+ using <xref linkend="PCP-DETACH-NODE"> command.
+ </para>
+
+ <para>
+ A <productname>PostgreSQL</productname> node detached by failover
+ or switch over will never return to the previous state (attached
+ state). Restarting <productname>Pgpool-II</productname> with -D
+ option or running <xref linkend="PCP-ATTACH-NODE"> makes it to
+ the attached state. It is recommended to confirm the
+ replication_state of <xref linkend="SQL-SHOW-POOL-NODES"> is
+ "streaming" before doing that. The state indicates that the
+ standby server is properly connected to the primary server
+ through streaming replication and both databases are in sync.
+ </para>
+
<sect2 id="runtime-config-failover-settings">
<title>Failover and Failback Settings</title>
projects / pgpool2.git / commitdiff