pgpool2.git / summary / log / commit / refs
commit c013bad08e67bd53d39a66835c67bc93d334d72b
Author: Takuma Hoshiai <hoshiai@sraoss.co.jp>
Date: Wed May 08 05:06:04 2019 +0000
Doc: update chapters that 'Server Configuration' of 'Server Administration'.
Reviewed by Tatsu Ishii and Bo Peng.
doc.ja/src/sgml/config.sgml | 7 ++--
doc.ja/src/sgml/connection-pooling.sgml | 5 ++-
doc.ja/src/sgml/connection-settings.sgml | 48 +++++++++++++++--------
doc.ja/src/sgml/intro.sgml | 21 ++++++++++
doc.ja/src/sgml/loadbalance.sgml | 9 +++--
doc.ja/src/sgml/memcache.sgml | 16 +++++++-
doc.ja/src/sgml/misc-config.sgml | 14 ++++++-
doc.ja/src/sgml/online-recovery.sgml | 66 ++++++++++++++++++++++++++------
doc.ja/src/sgml/ssl.sgml | 8 +++-
doc.ja/src/sgml/stream-check.sgml | 5 ++-
doc/src/sgml/config.sgml | 4 +-
doc/src/sgml/connection-pooling.sgml | 3 +-
doc/src/sgml/connection-settings.sgml | 34 ++++++++++------
doc/src/sgml/intro.sgml | 13 +++++++
doc/src/sgml/loadbalance.sgml | 7 ++--
doc/src/sgml/memcache.sgml | 8 ++++
doc/src/sgml/misc-config.sgml | 10 ++++-
doc/src/sgml/online-recovery.sgml | 45 ++++++++++++++++------
doc/src/sgml/ssl.sgml | 6 ++-
doc/src/sgml/stream-check.sgml | 3 +-
20 files changed, 255 insertions(+), 77 deletions(-)
diff --git a/doc.ja/src/sgml/config.sgml b/doc.ja/src/sgml/config.sgml
index 1fd2e142e..c2248aac2 100644
--- a/doc.ja/src/sgml/config.sgml
+++ b/doc.ja/src/sgml/config.sgml
@@ -139,10 +139,11 @@
<!--
The most fundamental way to set these parameters is to edit the file
<filename>pgpool.conf</><indexterm><primary>pgpool.conf</></>,
- which is located in <literal>$prefix/etc/pgpool.conf</literal>.
- An example of what this file might look like is:
+ which is located in <literal>$prefix/etc/pgpool.conf</literal>, if it
+ installed from source code. An example of what this file might look like is:
-->
-これらのパラメータを設定する最も基本的な方法は、<filename>pgpool.conf</><indexterm><primary>pgpool.conf</></>ファイルを編集することで、これは通常<literal>$prefix/ext/pgpool.conf</literal>に配置されています。
+これらのパラメータを設定する最も基本的な方法は、<filename>pgpool.conf</><indexterm><primary>pgpool.conf</></>ファイルを編集することです。
+ソースコードからインストールした場合、<literal>$prefix/ext/pgpool.conf</literal>に配置されています。
このファイルがどういったものかの例を示します。
<programlisting>
# This is a comment
diff --git a/doc.ja/src/sgml/connection-pooling.sgml b/doc.ja/src/sgml/connection-pooling.sgml
index cf67c8674..025c6ed2c 100644
--- a/doc.ja/src/sgml/connection-pooling.sgml
+++ b/doc.ja/src/sgml/connection-pooling.sgml
@@ -73,14 +73,15 @@ onに設定されるとバックエンドへの接続をキャッシュします
in each <productname>Pgpool-II</productname> child
process. <productname>Pgpool-II</productname> reuses the
cached connection if an incoming connection is connecting
- to the same database with the same user name. If not,
+ to the same database with the same user name and the same
+ run-time parameters. If not,
<productname>Pgpool-II</productname> creates a new
connection to the backend. If the number of cached
connections exceeds max_pool, the oldest connection will
be discarded, and uses that slot for the new connection.
-->
<productname>Pgpool-II</productname>の各子プロセスがキャッシュするコネクションの最大数です。
-<productname>Pgpool-II</productname>は、受け付けた接続が同じユーザ名で同じデータベースに接続しようとする場合に、キャッシュされたコネクションを再利用します。
+<productname>Pgpool-II</productname>は、受け付けた接続が同じユーザ名かつ同じ実行時パラメータで同じデータベースに接続しようとする場合に、キャッシュされたコネクションを再利用します。
そうでなければ<productname>Pgpool-II</productname>はバックエンドへの新しい接続を生成します。
もしキャッシュされている接続の数がmax_poolを超えた場合には、一番古いコネクションが廃棄され、そのスロットが新しい接続のために使用されます。
</para>
diff --git a/doc.ja/src/sgml/connection-settings.sgml b/doc.ja/src/sgml/connection-settings.sgml
index 3e4871004..6081a8590 100644
--- a/doc.ja/src/sgml/connection-settings.sgml
+++ b/doc.ja/src/sgml/connection-settings.sgml
@@ -243,18 +243,34 @@ num_init_childrenより多いクライアントが<productname>Pgpool-II</produc
num_init_children*<xref linkend="guc-listen-backlog-multiplier">
exceeds the number, you need to set the backlog higher.
Otherwise, following problems may occur in heavy loaded systems:
- 1) connecting to <productname>Pgpool-II</productname> fails
- 2) connecting to <productname>Pgpool-II</productname> is
- getting slow because of retries in the kernel. You can
- check if the listen queue is actually overflowed by using
- "netstat -s" command. If you find something like:
-->
待ち行列は、OS内部に作られ、「listenキュー」と呼ばれます。
listenキューの長さは「バックログ」と呼ばれます。
システムによってはバックログの上限が設定されており、<xref linkend="guc-listen-backlog-multiplier">*num_init_childrenがこれを越える場合はバックログを大きく設定する必要があります。
さもないと高負荷時に以下のような問題が発生する可能性があります:
-1) <productname>Pgpool-II</productname>への接続が失敗する。
-2) カーネル内で行われるリトライにより<productname>Pgpool-II</productname>への接続が遅くなる。
+ <itemizedlist>
+ <listitem>
+ <para>
+<!--
+ connecting to <productname>Pgpool-II</productname> fails
+-->
+<productname>Pgpool-II</productname>への接続が失敗する。
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!--
+ connecting to <productname>Pgpool-II</productname> is
+ getting slow because of retries in the kernel.
+-->
+カーネル内で行われるリトライにより<productname>Pgpool-II</productname>への接続が遅くなる。
+ </para>
+ </listitem>
+ </itemizedlist>
+<!--
+ You can check if the listen queue is actually overflowed by using
+ "netstat -s" command. If you find something like:
+-->
実際にlistenキューが溢れているかどうかは、"netstat -s"コマンドを使って確認できます。
もし、以下のような出力があった場合、
<programlisting>
@@ -589,7 +605,7 @@ AES256暗号化パスワードの詳細は、<xref linkend="auth-aes-encrypted-p
with another master/slave replication software (like <acronym>Slony-I</acronym>
and Streaming replication), that is responsible for doing the actual data replication.
-->
-このモードは<productname>Pgpool-II</productname>と（<acronym>Slony-I</acronym>やストリームレプリケーションのような）他のマスター/スレーブ型のレプリケーションソフトウェアと組み合わせるのに使用されます。
+このモードは<productname>Pgpool-II</productname>と（<acronym>Slony-I</acronym>やストリーミングレプリケーションのような）他のマスター/スレーブ型のレプリケーションソフトウェアと組み合わせるのに使用されます。
実際にデータレプリケーションを行うのはこれらのソフトウェアに任されます。
</para>
@@ -698,19 +714,19 @@ AES256暗号化パスワードの詳細は、<xref linkend="auth-aes-encrypted-p
<tbody>
<row>
- <entry><literal>'slony'</literal></entry>
+ <entry><literal>'stream'</literal></entry>
<!--
- <entry>Suitable for <acronym>Slony-I</acronym></entry>
+ <entry>Suitable for <productname>PostgreSQL</>'s built-in replication system (Streaming Replication)</entry>
-->
- <entry> <acronym>Slony-I</acronym>に適合</entry>
+ <entry><productname>PostgreSQL</>の組み込みレプリケーションシステム（ストリーミングレプリケーション）に適合</entry>
</row>
<row>
- <entry><literal>'stream'</literal></entry>
+ <entry><literal>'slony'</literal></entry>
<!--
- <entry>Suitable for <productname>PostgreSQL</>'s built-in replication system (Streaming Replication)</entry>
+ <entry>Suitable for <acronym>Slony-I</acronym></entry>
-->
- <entry><productname>PostgreSQL</>の組み込みレプリケーションシステム（ストリーミングレプリケーション）に適合</entry>
+ <entry> <acronym>Slony-I</acronym>に適合</entry>
</row>
<row>
@@ -727,9 +743,9 @@ AES256暗号化パスワードの詳細は、<xref linkend="auth-aes-encrypted-p
<para>
<!--
- Default is <literal>'slony'</literal>.
+ Default is <literal>'stream'</literal>.
-->
-デフォルトは<literal>'slony'</literal>です。
+デフォルトは<literal>'stream'</literal>です。
</para>
<para>
<!--
diff --git a/doc.ja/src/sgml/intro.sgml b/doc.ja/src/sgml/intro.sgml
index 092e57448..be795ab49 100644
--- a/doc.ja/src/sgml/intro.sgml
+++ b/doc.ja/src/sgml/intro.sgml
@@ -183,6 +183,27 @@ SELECTクエリをサーバに分散させ、システム全体のスループ
</listitem>
</varlistentry>
+ <varlistentry>
+<!--
+ <term>Online Recovery</term>
+-->
+ <term>オンラインリカバリ</term>
+ <listitem>
+ <para>
+<!--
+ <productname>Pgpool-II</productname> can perform online recovery of database
+ node by executing one command. When the online recovery is used with the
+ automated fail over, a detached node by fail over is possible to attach as
+ standby node automatically. It is possible to synchronize and attach new
+ <productname>PostgreSQL</productname> server too.
+-->
+<productname>Pgpool-II</productname>はコマンド一つでデータベースノードのオンラインリカバリができます。
+自動フェイルオーバと組み合わせることで、フェイルオーバにより切り離されたノードをスタンバイとして自動で復帰させることも可能です。
+新しいPostgreSQLサーバを同期しノードとして追加することもできます。
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term>レプリケーション</term>
<listitem>
diff --git a/doc.ja/src/sgml/loadbalance.sgml b/doc.ja/src/sgml/loadbalance.sgml
index 45dced289..59eae8eeb 100644
--- a/doc.ja/src/sgml/loadbalance.sgml
+++ b/doc.ja/src/sgml/loadbalance.sgml
@@ -41,11 +41,12 @@
<!--
If you don't want a query that qualifies for the load balancing to be
load balanced by <productname>Pgpool-II</productname>, you can put
- <emphasis>/*NO LOAD BALANCE*/</emphasis> comment before the <acronym>SELECT
- </acronym> statement. This will disable the load balance of the particular query
- and <productname>Pgpool-II</productname> will send it to the master node (the primary node in Master Slave mode).
+ arbitrary comment(<emphasis>/*NO LOAD BALANCE*/</emphasis> is usually used)
+ before the <acronym>SELECT</acronym> statement. This will disable the
+ load balance of the particular query and <productname>Pgpool-II</productname>
+ will send it to the master node (the primary node in Master Slave mode).
-->
-もし負荷分散対象のクエリを<productname>Pgpool-II</productname>に負荷分散してほしくない場合には、<acronym>SELECT</acronym>文の前の<emphasis>/*NO LOAD BALANCE*/</emphasis>コメントを付与することができます。
+もし負荷分散対象のクエリを<productname>Pgpool-II</productname>に負荷分散してほしくない場合には、<acronym>SELECT</acronym>文の前の任意のコメント（<emphasis>/*NO LOAD BALANCE*/</emphasis>がよく使われます）を付与することができます。
これにより、そのクエリの負荷分散は無効となり、<productname>Pgpool-II</productname>はこれをマスターノード（マスタースレーブモードではプライマリノード）に送信します。
</para>
</note>
diff --git a/doc.ja/src/sgml/memcache.sgml b/doc.ja/src/sgml/memcache.sgml
index 6ec5e3997..3668626e2 100644
--- a/doc.ja/src/sgml/memcache.sgml
+++ b/doc.ja/src/sgml/memcache.sgml
@@ -112,7 +112,21 @@ from the in memory cache is extremely fast.
This parameter can only be set at server start.
-->
このパラメータはサーバ起動時にのみ設定可能です。
-</para>
+ </para>
+
+ <note>
+ <para>
+ <!--
+ The query cache is used the relation cache too, if <xref linkend="guc-enable-shared-relcache"> is on.
+ You notes that the query cache is used regardless <xref linkend="guc-memory-cache-enabled"> parameter, when It is used by relation cache.
+ See <xref linkend="runtime-misc"> for more details to relation cache.
+ -->
+<xref linkend="guc-enable-shared-relcache">が有効の場合、クエリキャッシュはリレーションキャッシュでも使用されます。
+リレーションキャッシュで使用される場合、<xref linkend="guc-memory-cache-enabled">パラメータのオン、オフに関わらずクエリキャッシュが使用されることに注意してください。
+リレーションキャッシュの詳細は<xref linkend="runtime-misc">を参照してください。
+ </para>
+ </note>
+
</listitem>
</varlistentry>
</variablelist>
diff --git a/doc.ja/src/sgml/misc-config.sgml b/doc.ja/src/sgml/misc-config.sgml
index 39aa3412d..01d72d796 100644
--- a/doc.ja/src/sgml/misc-config.sgml
+++ b/doc.ja/src/sgml/misc-config.sgml
@@ -29,6 +29,8 @@
table is a temporary table or not). The cache is maintained in
the local memory space of <productname>Pgpool-II</productname>
child process and its lifetime is same as of the child process.
+ The cache is also maintained in shared memory to share among child
+ processes,if enable <xref linkend="guc-enable-shared-relcache">.
So If the table is modified using <command>ALTER TABLE</command>
or some other means, the relcache becomes inconsistent.
For this purpose, <varname>relcache_expire</varname> controls
@@ -38,6 +40,7 @@
リレーションキャッシュの寿命を秒単位で指定します。
リレーションキャッシュは、<productname>Pgpool-II</productname>がテーブルの構造を含む様々な情報を取得したり、テーブルのタイプ（たとえば、参照されているテーブルが一時テーブルかどうかなど）をチェックするために使う<productname>PostgreSQL</>のシステムカタログの問い合わせ結果を保存しておくものです。
キャッシュはpgpoolの子プロセスのローカルメモリ空間に保管されています。
+<xref linkend="guc-enable-shared-relcache">が有効な場合、子プロセス間で共有するために共有メモリにも保管されます。
もし<command>ALTER TABLE</command>でテーブルが変更された場合などは、リレーションキャッシュと一致しなくなります。
そのため、<varname>relcache_expire</varname>がキャッシュの寿命をコントロールしています。
デフォルトは0で、キャッシュの期限が切れることはありません。
@@ -66,11 +69,14 @@
<para>
<!--
- Specifies the number of relcache entries.
- Default is 256.
+ Specifies the number of relcache entries. Default is 256.
+ The cache is created about 10 entries per table. So you can estimate
+ the required number of relation cache at "number of using table * 10".
-->
リレーションキャッシュのエントリ数を指定します。
デフォルトは256です。
+リレーションキャッシュは、一つのテーブルあたり最大10個程度のエントリが作成されます。
+そのため、必要なリレーションキャッシュのサイズは、使用するテーブル数 * 10 で見積れます。
</para>
<note>
<para>
@@ -113,12 +119,16 @@
but using query cache can expect to execute only same query once.
Expiration time on query cache is <xref linkend="guc-relcache-expire"> parameter.
This parameter enables even if <xref linkend="guc-memory-cache-enabled"> is off.
+ In this case some query cache parameters(<xref linkend="guc-memqcache-method">,
+ <xref linkend="guc-memqcache-maxcache"> and each cache storage parameter)
+ is used together.
-->
onにするとクエリキャッシュを利用して子プロセス間でリレーションキャッシュを共有します。
デフォルトはoffです。
それぞれの子プロセスは<productname>PostgreSQL</productname>のシステムカタログを参照するために同じクエリを実行していましたが、クエリキャッシュにより同じクエリの実行を1回だけとすることが期待できます。
クエリキャッシュ上の寿命は、<xref linkend="guc-relcache-expire">の値となります。
本パラメータは、<xref linkend="guc-memory-cache-enabled">がoffの場合も有効です。
+この場合、一部のクエリキャッシュのパラメータ（<xref linkend="guc-memqcache-method">と<xref linkend="guc-memqcache-maxcache">、および各キャッシュストレージ用のパラメータ）も有効になります。
</para>
<para>
<!--
diff --git a/doc.ja/src/sgml/online-recovery.sgml b/doc.ja/src/sgml/online-recovery.sgml
index e33881ad2..1376996c9 100644
--- a/doc.ja/src/sgml/online-recovery.sgml
+++ b/doc.ja/src/sgml/online-recovery.sgml
@@ -37,10 +37,11 @@
<xref linkend="guc-backend-hostname"> and its associated
parameters. This will register the new server
to <productname>Pgpool-II</productname> as a detached backend
- node.
+ node, after that you execute <xref linkend="pcp-recovery-node"> command,
+ the server is add.
-->
新しい<productname>PostgreSQL</>サーバを動的に追加したい場合には、<xref linkend="guc-backend-hostname">および関連パラメータを追加した後に<filename>pgpool.conf</filename>を再読み込みします。
-これにより新しいサーバが切り離された状態のバックエンドノードとして<productname>Pgpool-II</productname>に登録されます。
+これにより新しいサーバが切り離された状態のバックエンドノードとして<productname>Pgpool-II</productname>に登録されるので、その後<xref linkend="pcp-recovery-node">コマンドを実行しサーバを追加できます。
</para>
<!--
<caution>
@@ -83,12 +84,8 @@ PostgreSQLのPITRを使っている場合は適用されません。
mode the second stage is not performed and you don't need to
provide a script for the stage
in <xref linkend="guc-recovery-2nd-stage-command">. i.e. you can
- safely leave it as an empty string.
-
- Online recovery is performed in two phases. Connections from cliens are
- not allowd in second phase of online recovery while the data can be
- updated or retrieved during the first phase.
- <productname>Pgpool-II</productname> performs the follows steps in online recovery:
+ safely leave it as an empty string. Those scripts example can be found in
+ <xref linkend="example-cluster-pgpool-config-online-recovery">.
-->
オンラインリカバリは2段階に分けて実施されます。
第1段階は「ファーストステージ」、第2段階は「セカンドステージ」と呼ばれます。
@@ -96,6 +93,7 @@ PostgreSQLのPITRを使っている場合は適用されません。
<xref linkend="guc-replication-mode">の時のみセカンドステージが必要です。
ストリーミングレプリケーションモードを含むその他のモードでは、セカンドステージは実施されず、<xref linkend="guc-recovery-2nd-stage-command">用のスクリプトを用意する必要はありません。
つまり、そのエントリを空文字にしておいても問題ありません。
+これらのスクリプトの例は<xref linkend="example-cluster-pgpool-config-online-recovery">にあります。
</para>
<para>
<!--
@@ -153,6 +151,45 @@ PostgreSQLのPITRを使っている場合は適用されません。
-->
postmasterの起動（<literal>pgpool_remote_start</literal>の実施）
</para>
+ <para>
+<!--
+ The <literal>pgpool_remote_start</literal> is script to start up the <productname>PostgreSQL</productname> node of recovery target.
+ <literal>pgpool_remote_start</literal> receives following 2 parameters:
+-->
+<literal>pgpool_remote_start</literal>は、リカバリ対象の<productname>PostgreSQL</productname>を起動するためのスクリプトです。
+<literal>pgpool_remote_start</literal>は次の2つの引数を受けとります。
+ <itemizedlist>
+ <listitem>
+ <para>
+<!--
+ Hostname of the backend node to be recovered.
+-->
+リカバリされるバックエンドノードのホスト名
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!--
+ Path to the database cluster of the master(primary) node.
+-->
+リカバリされるバックエンドノードのデータベースクラスタへのパス
+ </para>
+ </listitem>
+ </itemizedlist>
+<!--
+ The script example can be found in <xref linkend="example-cluster-pgpool-config-online-recovery">.
+-->
+スクリプトの例は<xref linkend="example-cluster-pgpool-config-online-recovery">にあります。
+ <note>
+ <para>
+<!--
+ The script path and filename are hard coded, <command>$PGDATA/pgpool_remote_start</command> is executed on master(primary) node.
+-->
+スクリプトのパスおよびファイル名は固定されており、マスタ(プライマリ)ノード上で<command>$PGDATA/pgpool_remote_start</command>が実行されます。
+
+ </para>
+ </note>
+ </para>
</listitem>
<listitem>
<para>
@@ -197,8 +234,12 @@ postmasterの起動（<literal>pgpool_remote_start</literal>の実施）
<para>
<!--
Specifies the <productname>PostgreSQL</> user name to perform online recovery.
+ <varname>recovery_user</varname> must specify superuser,
+ beacause <function>pgpool_recovery</function> function is executed
+ during online recovery, require superuser privilege.
-->
オンラインリカバリを行うための<productname>PostgreSQL</>ユーザ名です。
+オンラインリカバリで実行される<function>pgpool_recovery</function>関数はPostgreSQLのスーパーユーザ権限が必要なため、<varname>recovery_user</varname>にスーパーユーザを指定しなければなりません。
</para>
<para>
<!--
@@ -416,15 +457,18 @@ rsync used in the command is killed by signal 2 for example.
<para>
<!--
- Specifies a command file to be run by master(primary) node at the
- second stage of online recovery. The command file must be placed in the
+ Specifies a command to be run by master node at the second
+ stage of online recovery. This command is required only
+ <xref linkend="guc-replication-mode">, so for other modes don't need
+ to provide a command file. The command file must be placed in the
database cluster directory for security reasons.
For example, if <varname>recovery_2nd_stage_command</varname> = <literal>
'sync-command'</literal>, then <productname>Pgpool-II</productname> will
look for the command scrit in <literal>$PGDATA</literal> directory and will
try to execute <command>$PGDATA/sync-command</command>.
-->
-オンラインリカバリのセカンドステージでマスタ（プライマリ）ノードで実行されるコマンドを指定します。
+オンラインリカバリのセカンドステージでマスタノードで実行されるコマンドを指定します。
+これは<xref linkend="guc-replication-mode">時のみ必要であるため、他のモードではコマンドファイルを用意する必要はありません。
コマンドファイルはセキュリティ上の観点からデータベースクラスタ内に配置される必要があります。
例えば、<varname>recovery_2nd_stage_command</varname> = <literal>'sync-command'</literal>となっている場合、<productname>Pgpool-II</productname>はコマンドスクリプトを<literal>$PGDATA</literal>ディレクトリの中で探し、<command>$PGDATA/sync-command</command>を起動しようとします。
</para>
diff --git a/doc.ja/src/sgml/ssl.sgml b/doc.ja/src/sgml/ssl.sgml
index d81c29598..0c38be668 100644
--- a/doc.ja/src/sgml/ssl.sgml
+++ b/doc.ja/src/sgml/ssl.sgml
@@ -73,11 +73,13 @@ SSLサポートを有効にするためには、<productname>Pgpool-II</productn
<para>
<!--
Specifies the path to the private key file to be used for
- incoming frontend connections.
+ incoming frontend connections. If specifies relative path, it is based
+ on the directory where pgpool is starting up.
There is no default value for this option, and if left unset
<acronym>SSL</acronym> will be disabled for incoming frontend connections.
-->
フロントエンドとの接続に使用するプライベートキーファイルのパスを指定します。
+相対パスで指定した場合、Pgpool-IIの実行ディレクトリが基準となります。
このオプションのデフォルト値はありません。
設定がない場合は、フロントエンドとの接続で<acronym>SSL</acronym>が使用されなくなります。
</para>
@@ -103,11 +105,13 @@ SSLサポートを有効にするためには、<productname>Pgpool-II</productn
<para>
<!--
Specifies the path to the public x509 certificate file to be used
- for the incoming frontend connections.
+ for the incoming frontend connections. If specifies relative path, based
+ path is Pgpool-II is run directory.
There is no default value for this option, and if left unset
<acronym>SSL</acronym> will be disabled for incoming frontend connections.
-->
フロントエンドとの接続に使用する公開x509証明書のフルパスを指定します。
+相対パスで指定した場合、Pgpool-IIの実行ディレクトリが基準となります。
このオプションのデフォルト値はありません。
設定がない場合は、フロントエンドとの接続で<acronym>SSL</acronym>が使用されなくなります。
</para>
diff --git a/doc.ja/src/sgml/stream-check.sgml b/doc.ja/src/sgml/stream-check.sgml
index f722bec70..bee06508c 100644
--- a/doc.ja/src/sgml/stream-check.sgml
+++ b/doc.ja/src/sgml/stream-check.sgml
@@ -74,10 +74,11 @@
<para>
<!--
Specifies the <productname>PostgreSQL</> user name to perform streaming replication check.
- The user must exist on all the <productname>PostgreSQL</> backends.
+ The user must have LOGIN privilege and exist on all the
+ <productname>PostgreSQL</> backends.
-->
ストリーミングレプリケーションのチェックを行う<productname>PostgreSQL</>ユーザ名を指定します。
-このユーザは、すべてのバックエンドに存在しなければなりません。
+このユーザはLOGIN権限を持ち、すべてのバックエンドに存在しなければなりません。
</para>
<note>
<para>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e9e573eaa..044af5717 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -79,8 +79,8 @@
<para>
The most fundamental way to set these parameters is to edit the file
<filename>pgpool.conf</><indexterm><primary>pgpool.conf</></>,
- which is located in <literal>$prefix/etc/pgpool.conf</literal>.
- An example of what this file might look like is:
+ which is located in <literal>$prefix/etc/pgpool.conf</literal>, if it
+ installed from source code. An example of what this file might look like is:
<programlisting>
# This is a comment
listen_addresses = 'localhost'
diff --git a/doc/src/sgml/connection-pooling.sgml b/doc/src/sgml/connection-pooling.sgml
index b61d893bb..5106e2d84 100644
--- a/doc/src/sgml/connection-pooling.sgml
+++ b/doc/src/sgml/connection-pooling.sgml
@@ -48,7 +48,8 @@
in each <productname>Pgpool-II</productname> child
process. <productname>Pgpool-II</productname> reuses the
cached connection if an incoming connection is connecting
- to the same database with the same user name. If not,
+ to the same database with the same user name and the same
+ run-time parameters. If not,
<productname>Pgpool-II</productname> creates a new
connection to the backend. If the number of cached
connections exceeds max_pool, the oldest connection will
diff --git a/doc/src/sgml/connection-settings.sgml b/doc/src/sgml/connection-settings.sgml
index 75c864c34..569bca552 100644
--- a/doc/src/sgml/connection-settings.sgml
+++ b/doc/src/sgml/connection-settings.sgml
@@ -156,12 +156,22 @@
length of the listen queue is called "backlog". There is
an upper limit of the backlog in some systems, and if
num_init_children*<xref linkend="guc-listen-backlog-multiplier">
- exceeds the number, you need to set the backlog higher.
- Otherwise, following problems may occur in heavy loaded systems:
- 1) connecting to <productname>Pgpool-II</productname> fails
- 2) connecting to <productname>Pgpool-II</productname> is
- getting slow because of retries in the kernel. You can
- check if the listen queue is actually overflowed by using
+ exceeds the number, you need to set the backlog higher.
+ Otherwise, following problems may occur in heavy loaded systems:
+ <itemizedlist>
+ <listitem>
+ <para>
+ connecting to <productname>Pgpool-II</productname> fails
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ connecting to <productname>Pgpool-II</productname> is
+ getting slow because of retries in the kernel.
+ </para>
+ </listitem>
+ </itemizedlist>
+ You can check if the listen queue is actually overflowed by using
"netstat -s" command. If you find something like:
<programlisting>
535 times the listen queue of a socket overflowed
@@ -452,11 +462,6 @@
</thead>
<tbody>
- <row>
- <entry><literal>'slony'</literal></entry>
- <entry>Suitable for <acronym>Slony-I</acronym></entry>
- </row>
-
<row>
<entry><literal>'stream'</literal></entry>
<entry>Suitable
@@ -464,6 +469,11 @@
replication system (Streaming Replication)</entry>
</row>
+ <row>
+ <entry><literal>'slony'</literal></entry>
+ <entry>Suitable for <acronym>Slony-I</acronym></entry>
+ </row>
+
<row>
<entry><literal>'logical'</literal></entry>
<entry>Suitable
@@ -476,7 +486,7 @@
</table>
<para>
- Default is <literal>'slony'</literal>.
+ Default is <literal>'stream'</literal>.
</para>
<para>
This parameter can only be set at server start.
diff --git a/doc/src/sgml/intro.sgml b/doc/src/sgml/intro.sgml
index 9a4916c36..f1b563ea2 100644
--- a/doc/src/sgml/intro.sgml
+++ b/doc/src/sgml/intro.sgml
@@ -126,6 +126,19 @@
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>Online Recovery</term>
+ <listitem>
+ <para>
+ <productname>Pgpool-II</productname> can perform online recovery of database
+ node by executing one command. When the online recovery is used with the
+ automated fail over, a detached node by fail over is possible to attach as
+ standby node automatically. It is possible to synchronize and attach new
+ <productname>PostgreSQL</productname> server too.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term>Replication</term>
<listitem>
diff --git a/doc/src/sgml/loadbalance.sgml b/doc/src/sgml/loadbalance.sgml
index 75bd39f70..bd6e05f68 100644
--- a/doc/src/sgml/loadbalance.sgml
+++ b/doc/src/sgml/loadbalance.sgml
@@ -25,9 +25,10 @@
<para>
If you don't want a query that qualifies for the load balancing to be
load balanced by <productname>Pgpool-II</productname>, you can put
- <emphasis>/*NO LOAD BALANCE*/</emphasis> comment before the <acronym>SELECT
- </acronym> statement. This will disable the load balance of the particular query
- and <productname>Pgpool-II</productname> will send it to the master node (the primary node in Master Slave mode).
+ arbitrary comment(<emphasis>/*NO LOAD BALANCE*/</emphasis> is usually used)
+ before the <acronym>SELECT</acronym> statement. This will disable the
+ load balance of the particular query and <productname>Pgpool-II</productname>
+ will send it to the master node (the primary node in Master Slave mode).
</para>
</note>
diff --git a/doc/src/sgml/memcache.sgml b/doc/src/sgml/memcache.sgml
index 0983b4a43..02805f454 100644
--- a/doc/src/sgml/memcache.sgml
+++ b/doc/src/sgml/memcache.sgml
@@ -69,6 +69,14 @@
<para>
This parameter can only be set at server start.
</para>
+
+ <note>
+ <para>
+ The query cache is used the relation cache too, if <xref linkend="guc-enable-shared-relcache"> is on.
+ You notes that the query cache is used regardless <xref linkend="guc-memory-cache-enabled"> parameter, when It is used by relation cache.
+ See <xref linkend="runtime-misc"> for more details to relation cache.
+ </para>
+ </note>
</listitem>
</varlistentry>
</variablelist>
diff --git a/doc/src/sgml/misc-config.sgml b/doc/src/sgml/misc-config.sgml
index 5b27f483d..d094a1616 100644
--- a/doc/src/sgml/misc-config.sgml
+++ b/doc/src/sgml/misc-config.sgml
@@ -22,6 +22,8 @@
table is a temporary table or not). The cache is maintained in
the local memory space of <productname>Pgpool-II</productname>
child process and its lifetime is same as of the child process.
+ The cache is also maintained in shared memory to share among child
+ processes,if enable <xref linkend="guc-enable-shared-relcache">.
So If the table is modified using <command>ALTER TABLE</command>
or some other means, the relcache becomes inconsistent.
For this purpose, <varname>relcache_expire</varname> controls
@@ -45,8 +47,9 @@
<listitem>
<para>
- Specifies the number of relcache entries.
- Default is 256.
+ Specifies the number of relcache entries. Default is 256.
+ The cache is created about 10 entries per table. So you can estimate
+ the required number of relation cache at "number of using table * 10".
</para>
<note>
<para>
@@ -79,6 +82,9 @@
but using query cache can expect to execute only same query once.
Expiration time on query cache is <xref linkend="guc-relcache-expire"> parameter.
This parameter enables even if <xref linkend="guc-memory-cache-enabled"> is off.
+ In this case some query cache parameters(<xref linkend="guc-memqcache-method">,
+ <xref linkend="guc-memqcache-maxcache"> and each cache storage parameter)
+ is used together.
</para>
<para>
<productname>Pgpool-II</productname> searh relation cache on local
diff --git a/doc/src/sgml/online-recovery.sgml b/doc/src/sgml/online-recovery.sgml
index f1c9d3379..f0d542d9e 100644
--- a/doc/src/sgml/online-recovery.sgml
+++ b/doc/src/sgml/online-recovery.sgml
@@ -24,7 +24,8 @@
<xref linkend="guc-backend-hostname"> and its associated
parameters. This will register the new server
to <productname>Pgpool-II</productname> as a detached backend
- node.
+ node, after that you execute <xref linkend="pcp-recovery-node"> command,
+ the server is add.
</para>
<!--
<caution>
@@ -59,7 +60,8 @@
mode the second stage is not performed and you don't need to
provide a script for the stage
in <xref linkend="guc-recovery-2nd-stage-command">. i.e. you can
- safely leave it as an empty string.
+ safely leave it as an empty string. Those scripts example can be found in
+ <xref linkend="example-cluster-pgpool-config-online-recovery">.
</para>
<para>
Connections from cliens are not allowd only in the second stage
@@ -102,6 +104,28 @@
<para>
Start up postmaster (perform <literal>pgpool_remote_start</literal>)
</para>
+ <para>
+ The <literal>pgpool_remote_start</literal> is script to start up the <productname>PostgreSQL</productname> node of recovery target.
+ <literal>pgpool_remote_start</literal> receives following 2 parameters:
+ <itemizedlist>
+ <listitem>
+ <para>
+ Hostname of the backend node to be recovered.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Path to the database cluster of the master(primary) node.
+ </para>
+ </listitem>
+ </itemizedlist>
+ The script example can be found in <xref linkend="example-cluster-pgpool-config-online-recovery">.
+ <note>
+ <para>
+ The script path and filename are hard coded, <command>$PGDATA/pgpool_remote_start</command> is executed on master(primary) node.
+ </para>
+ </note>
+ </para>
</listitem>
<listitem>
<para>
@@ -278,15 +302,14 @@ rsync used in the command is killed by signal 2 for example.
<para>
Specifies a command to be run by master node at the second
- stage of online recovery. This parameter only neccessary for
- <xref linkend="guc-replication-mode">. The command file must
- be placed in the database cluster directory for security
- reasons. For example,
- if <varname>recovery_2nd_stage_command</varname> = <literal>
- 'sync-command'</literal>,
- then <productname>Pgpool-II</productname> will look for the
- command scrit in <literal>$PGDATA</literal> directory and
- will try to execute <command>$PGDATA/sync-command</command>.
+ stage of online recovery. This command is required only
+ <xref linkend="guc-replication-mode">, so for other modes don't need
+ to provide a command file. The command file must be placed in the
+ database cluster directory for security reasons.
+ For example, if <varname>recovery_2nd_stage_command</varname> = <literal>
+ 'sync-command'</literal>, then <productname>Pgpool-II</productname> will
+ look for the command scrit in <literal>$PGDATA</literal> directory and will
+ try to execute <command>$PGDATA/sync-command</command>.
</para>
<para>
<varname>recovery_2nd_stage_command</varname> receives following 5 parameters:
diff --git a/doc/src/sgml/ssl.sgml b/doc/src/sgml/ssl.sgml
index 1525fd43e..1fda76195 100644
--- a/doc/src/sgml/ssl.sgml
+++ b/doc/src/sgml/ssl.sgml
@@ -49,7 +49,8 @@
<listitem>
<para>
Specifies the path to the private key file to be used for
- incoming frontend connections.
+ incoming frontend connections. If specifies relative path, it is based
+ on the directory where pgpool is starting up.
There is no default value for this option, and if left unset
<acronym>SSL</acronym> will be disabled for incoming frontend connections.
</para>
@@ -68,7 +69,8 @@
<listitem>
<para>
Specifies the path to the public x509 certificate file to be used
- for the incoming frontend connections.
+ for the incoming frontend connections. If specifies relative path, based
+ path is Pgpool-II is run directory.
There is no default value for this option, and if left unset
<acronym>SSL</acronym> will be disabled for incoming frontend connections.
</para>
diff --git a/doc/src/sgml/stream-check.sgml b/doc/src/sgml/stream-check.sgml
index 79205e57e..621c0b74d 100644
--- a/doc/src/sgml/stream-check.sgml
+++ b/doc/src/sgml/stream-check.sgml
@@ -49,7 +49,8 @@
<para>
Specifies the <productname>PostgreSQL</> user name to perform streaming replication check.
- The user must exist on all the <productname>PostgreSQL</> backends.
+ The user must have LOGIN privilege and exist on all the
+ <productname>PostgreSQL</> backends.
</para>
<note>
<para>
[parent: 552064f640d9]