pgpool2.git - commit e6a908636abb

pgpool2.git / summary / log / commit / refs

commit    e6a908636abbcba3e6c0f32d05fee354583e5adf
Author:   Tatsuo Ishii <ishii@sraoss.co.jp>
Date:     Wed May 15 08:01:51 2019 +0000

    Add general description about failover.


 doc.ja/src/sgml/failover.sgml | 52 ++++++++++++++++++++++++-
 doc/src/sgml/failover.sgml    | 90 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 141 insertions(+), 1 deletion(-)

diff --git a/doc.ja/src/sgml/failover.sgml b/doc.ja/src/sgml/failover.sgml
index 5ab9d7012..a1c73d886 100644
--- a/doc.ja/src/sgml/failover.sgml
+++ b/doc.ja/src/sgml/failover.sgml
@@ -6,8 +6,58 @@
 -->
  <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>
 -->
diff --git a/doc/src/sgml/failover.sgml b/doc/src/sgml/failover.sgml
index 64cf7e227..2504baef2 100644
--- a/doc/src/sgml/failover.sgml
+++ b/doc/src/sgml/failover.sgml
@@ -3,6 +3,96 @@
 <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>


[parent: 3dd1cd3f1528]